From report at bugs.python.org  Fri Jul  1 00:04:24 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Jun 2011 22:04:24 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309471464.58.0.837170345558.issue8716@psf.upfronthosting.co.za>


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

I think this issue should be considered a test environment error.  Since this buildbot is set up in an environment where it is "running headless", that is to say the tests are run under a username that is not logged in to the window server, we should not be trying to run GUI tests there, in particular Tkinter tests.  Yes, in a better world, Aqua TK on OS X should not crash in this situation but it is not a Python bug that it does and it's a bit of a hassle to workaround the Tk bug by trying to determine whether the interpreter is indeed running under a user id that is currently also logged in as the primary GUI user.  Also note that there has been no update on the status of the Tk bug that Ronald filed a year ago; not surprisingly, it's not considered an important issue by the project and it's likely not that important for them to make the effort to fix it.  In the real world, this situation does not happen; you would only be running Tkinter stuff if you are logged in as the current GUI user and then the test does not crash.  So, for this and any other OS X buildbot "running headless", the buildbot configuration should be changed to skip GUI tests:

   make buildbottest TESTOPTS='-uall,-gui'

Can someone with access to the buildbot configuration make that change and ensure the crash goes away?

----------

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

From report at bugs.python.org  Fri Jul  1 00:04:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 22:04:57 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1309471497.16.0.648321847057.issue9561@psf.upfronthosting.co.za>


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

> Okay.  I guess you?ll use codecs.open in 2.7

Oh, Python 2.7... DistributionMetadata of distutils encodes most values to byte strings (get_xxx() methods calls self._encode_field). It would be possible to use codecs.open(), but an Unicode file expects Unicode strings. The problem is that the user may provide arbitrary byte strings, I mean strings not encoded to PKG_INFO_ENCODING. Even if such strings are *wrong* (not correctly encoded), is it a good idea to be more strict in a minor version (2.7.x)?

I don't want to be responsible of such tricky change, I prefer to leave distutils unchanged in Python 2.7 (at least for PKG-INFO).

> please make sure there is no bootstrapping issue
> for the build of CPython itself.

I checked, there is not bootstrap issue.

----------

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

From report at bugs.python.org  Fri Jul  1 00:12:17 2011
From: report at bugs.python.org (Renaud Blanch)
Date: Thu, 30 Jun 2011 22:12:17 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1309471937.53.0.884345205628.issue11682@psf.upfronthosting.co.za>


Renaud Blanch <rndblnch at gmail.com> added the comment:

I've just updated the pep380-test patch to make it slightly simpler (still in golden output form though)

https://bitbucket.org/rndblnch/cpython-pep380/src/317eadf5e3e8/pep380-tests

----------

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

From report at bugs.python.org  Fri Jul  1 00:22:44 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Jun 2011 22:22:44 +0000
Subject: [issue5120] Change _tkinter initialization for new versions of Aqua
	Tk on OS X
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1309472564.92.0.97408984563.issue5120@psf.upfronthosting.co.za>


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

See comments to Issue8716. Suggest any further comments on the "headless" crash issue go there and reserve this issue for investigation into the suggested changes to initialization when using Aqua Tk.  BTW, the supplied patch has compile time Tk version tests which can be problematic since Aqua Tk is dynamically linked and so the exact patch version cannot be determined at compile time.  However, since 8.4.7 is the earliest version we claim to support we could probably dispense with the check, assuming the change is warranted.

----------
nosy:  -BreamoreBoy
title: Disabling test_ttk_guionly on mac -> Change _tkinter initialization for new versions of Aqua Tk on OS X
type: crash -> 
versions: +Python 3.2, Python 3.3 -Python 3.1

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

From report at bugs.python.org  Fri Jul  1 00:46:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 22:46:38 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309473998.93.0.925136865472.issue8716@psf.upfronthosting.co.za>


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

> Since this buildbot is set up in an environment where it is
> "running headless", that is to say the tests are run under
> a username that is not logged in to the window server, we should
> not be trying to run GUI tests there, in particular Tkinter tests.

If I run test_ttk_guionly in SSH, the process abort. gdb trace:
-----------------------
...
kCGErrorRangeCheck : Window Server communications from outside of session allowed for root and console user only
INIT_Processeses(), could not establish the default connection to the WindowServer.
Program received signal SIGABRT, Aborted.
0x9003d66c in kill ()
(gdb) where
#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x917d7dad in RegisterProcess ()
#4  0x917d7b55 in INIT_Processes ()
#5  0x918080b6 in ProcessManagerLazyInitialization ()
#6  0x917d7aa6 in GetCurrentProcess ()
#7  0x92dd5ef9 in GetSystemUIMode ()
#8  0x92dd5e86 in IsMenuBarVisible ()
#9  0x92e2af35 in GetAvailableWindowPositioningBounds ()
#10 0x0b0a7a31 in TkMacOSXDisplayChanged ()
#11 0x0b0a7bee in TkpOpenDisplay ()
#12 0x0b02ace6 in CreateTopLevelWindow ()
#13 0x0b02b0dd in TkCreateMainWindow ()
#14 0x0b035115 in CreateFrame ()
#15 0x0b035544 in TkCreateFrame ()
#16 0x0b02c564 in Initialize ()
#17 0x010d2789 in Tcl_AppInit (interp=0x12c6010) at /Users/vstinner/cpython/Modules/tkappinit.c:106
#18 0x010cc000 in Tkapp_New (screenName=0x0, className=0x10d2e8c "Tk", interactive=0, wantobjects=0, wantTk=1, sync=0, use=0x0) at /Users/vstinner/cpython/Modules/_tkinter.c:724
#19 0x010d1dcd in Tkinter_Create (self=0x1275838, args=0x517038) at /Users/vstinner/cpython/Modules/_tkinter.c:2938
#20 0x00060241 in PyCFunction_Call (func=0x106c338, arg=0x517038, kw=0x0) at Objects/methodobject.c:81
#21 0x0008de54 in call_function (pp_stack=0xbffff164, oparg=0) at Python/ceval.c:3957
#22 0x00087f81 in PyEval_EvalFrameEx (f=0x1255d28, throwflag=0) at Python/ceval.c:2663
#23 0x0008bf7d in PyEval_EvalCodeEx (_co=0x7a7df8, globals=0x705428, locals=0x705428, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3393
#24 0x00079362 in PyEval_EvalCode (co=0x7a7df8, globals=0x705428, locals=0x705428) at Python/ceval.c:767
#25 0x000e1a9f in run_mod (mod=0x18bdba0, filename=0x1caac8 "<string>", globals=0x705428, locals=0x705428, flags=0xbffffa34, arena=0x1101470) at Python/pythonrun.c:1793
#26 0x000e17a4 in PyRun_StringFlags (str=0x125f520 "import _tkinter; c=_tkinter.create(); print(\"a\")\n", start=257, globals=0x705428, locals=0x705428, flags=0xbffffa34) at Python/pythonrun.c:1727
#27 0x000dfe61 in PyRun_SimpleStringFlags (command=0x125f520 "import _tkinter; c=_tkinter.create(); print(\"a\")\n", flags=0xbffffa34) at Python/pythonrun.c:1300
#28 0x0000714c in run_command (command=0x11010e0, cf=0xbffffa34) at Modules/main.c:260
#29 0x00007f4a in Py_Main (argc=3, argv=0x514028) at Modules/main.c:634
#30 0x000024d3 in main (argc=3, argv=0xbffffb6c) at ./Modules/python.c:59
-----------------------

The best would be to fix _tkinter to catch Tk error, but I agree, in a first time we may just try to detect that we cannot create GUI objects. For example, test if the DISPLAY environment variable is present.

"PPC Tiger 3.x": test_ttk_guionly crashs sometimes, the variable is not set.

"AMD64 Leopard 3.x": test_tcl, test_tk, test_ttk_guionly and test_ttk_textonly are skipped; the variable is set (e.g. DISPLAY=/tmp/launch-lDC93s/:0).

"AMD64 Snow Leopard 2 3.x": test_ttk_guionly pass, DISPLAY var is set (e.g. DISPLAY=/tmp/launch-cuyZPv/org.x:0).

Attached requires_tkinter.patch file adds the check for test_tk and test_ttk_guionly.

----------

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

From report at bugs.python.org  Fri Jul  1 00:47:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 22:47:08 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309474028.69.0.795636082686.issue8716@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file22527/requires_tkinter.patch

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

From report at bugs.python.org  Fri Jul  1 00:54:29 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 30 Jun 2011 22:54:29 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309474469.35.0.223581202887.issue12455@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

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

From report at bugs.python.org  Fri Jul  1 01:11:47 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Jun 2011 23:11:47 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309475507.39.0.881539581277.issue8716@psf.upfronthosting.co.za>


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

Victor, I don't understand what your patch is trying to accomplish.  The problem is not that Tkinter isn't built; the problem is simply at execution time.  Yes, you'll see exactly the same behavior if you are logged in via ssh and the usename you are running under is not logged in as the main GUI user.  The solution is to not run Tkinter stuff in that situation.

----------

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

From report at bugs.python.org  Fri Jul  1 01:13:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 23:13:16 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309475596.58.0.88516190419.issue8716@psf.upfronthosting.co.za>


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

> Victor, I don't understand what your patch is trying to accomplish.

It skips test_tk and test_ttk_guionly if the DISPLAY environment variable is not set.

----------

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

From report at bugs.python.org  Fri Jul  1 01:24:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Jun 2011 23:24:30 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309476270.11.0.811724744564.issue8716@psf.upfronthosting.co.za>


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

> It skips test_tk and test_ttk_guionly if the DISPLAY environment variable is not set.

Whether DISPLAY is set or not isn't relevant.  What's relevant is whether I'm logged in as the GUI user.  In this example, I'm logging in through ssh using the same user name that is currently logged in as the main GUI user.

   $ ssh xxxx
   $ echo $DISPLAY

   $ /usr/local/bin/python3.2 -m test -u gui test_ttk_guionly
   [1/1] test_ttk_guionly
   1 test OK. 

It's really not worth trying to fix the tests.  The buildbot configuration is incorrect.

----------

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

From report at bugs.python.org  Fri Jul  1 01:29:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jun 2011 23:29:51 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309476591.97.0.592394510474.issue8716@psf.upfronthosting.co.za>


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

@pitrou: How can we fix the configuration of the buildbot?

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Jul  1 02:16:05 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 01 Jul 2011 00:16:05 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309479365.63.0.581224967091.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file22528/c3ba4f7b5db1.diff

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

From report at bugs.python.org  Fri Jul  1 02:16:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 00:16:35 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309479395.78.0.399231374236.issue8716@psf.upfronthosting.co.za>


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

As discussed on IRC, updated patch skipping test_tk and test_ttk_guionly very early if the gui resource is not set.

----------
Added file: http://bugs.python.org/file22529/requires_tkinter-2.patch

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

From report at bugs.python.org  Fri Jul  1 02:35:12 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 01 Jul 2011 00:35:12 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1309461928.3214.15.camel@localhost.localdomain>
Message-ID: <1309480509.24556.YahooMailRC@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

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

> It's not proscribed, but trying to remove the "self." because  it's
> supposed to be more readable is a bit of a strange thing to do.
> Also,  people reading the test suite should be accustomed to
> "self.assertEqual"  anyway, so there's no point trying to hide it.

It wasn't particularly about self - I'm not against it. Anyway, it's not a big 
deal for me, so I've added the selves back :-)

> Error checking can't  just be probabilistic. Perhaps there's a bug in the
> file-like object; or  perhaps it is a non-blocking IO object and read()
> will return None at  times.

You're right, so I've raised a TypeError if PyBytes_Check fails in r_string.

> Well, it  wouldn't fail any slower if you didn't do it, since you need to
> call read()  very soon anyway (presumably as part of the same call to
> marshal.load()).  Failing "fast" doesn't seem to bring anything here. My
> vote is for removing  the  complication.

Actually I misremembered the complete reason for the call - it was there to 
additionally check that the passed object has a read method. I also realised - 
duh - that I can read zero bytes and still get an empty bytes object back, so 
I've done that, and it does look cleaner. I've also reorganised the marshal_load 
function a little so it flows better.

Your other points have also all been addressed:

I've seen that the original test with the long binary data was exercising the 
same functionality as Engelbert Gruber's later patch was testing. So I've 
removed my earlier test entirely and added tuples and lists into the data being 
marshalled in Engelbert's version of the test. As a result of these changes, the 
zlib/base64 dependency goes away.

The new "readable" field of the C struct has a comment saying what it is.

The commented out r_byte macro has been removed.

Thanks, again, for the review!

----------

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

From report at bugs.python.org  Fri Jul  1 02:44:29 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 01 Jul 2011 00:44:29 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1309481069.55.0.502140121926.issue12449@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

I can only do wxPython, I have no idea how Python's MSI installers work. I did a quick search for "Finish" in the codebase but could find any obvious place to add the accelerator.

"As a new feature, this cannot go into distutils."

Seriously? Why?

----------

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

From report at bugs.python.org  Fri Jul  1 03:12:51 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 01 Jul 2011 01:12:51 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309482771.49.0.72817135957.issue12291@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file22530/9993567039c0.diff

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

From report at bugs.python.org  Fri Jul  1 03:17:12 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 01 Jul 2011 01:17:12 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309483032.63.0.796480334698.issue12291@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

As a result of the changes to marshal.c, test_importlib needs a small change: the test_bad_marshal raises an EOFError now, whereas it raised ValueError before.

I think it's because the earlier code in marshal didn't properly check for EOF conditions in some places.

So I've changes the assertRaises(ValueError) to assertRaises(EOFError).

All tests now pass, other than test_ftplib (not related).

----------

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

From report at bugs.python.org  Fri Jul  1 03:47:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jul 2011 01:47:59 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309484879.11.0.224696996934.issue8716@psf.upfronthosting.co.za>


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

If I ssh in to a machine, python should not *crash* if I run gui stuff.  The test suite might generate errors rather than skips (although I would argue that it should generate skips), but it should not crash.

On the other hand I agree that fixing the buildbot config is a reasonable interim solution to the buildbot problem.

----------

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

From report at bugs.python.org  Fri Jul  1 03:57:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Jul 2011 01:57:21 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309485441.92.0.375176239748.issue8716@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/issue8716>
_______________________________________

From report at bugs.python.org  Fri Jul  1 07:25:23 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 01 Jul 2011 05:25:23 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>


New submission from Ross Lagerwall <rosslagerwall at gmail.com>:

6d6099f7fe89 introduced a regression.

It causes the following code to hang fairly reliably for me:
"""
import concurrent.futures
import math

def is_prime(n):
    print(sqt(81))  <---- Note the type error!

def main():
    with concurrent.futures.ProcessPoolExecutor(2) as executor:
        executor.map(is_prime, [1, 2])

if __name__ == '__main__':
    main()
"""

>From my limited knowledge of multiprocessing and concurrent futures, it seems that in shutdown_worker(), call_queue.put(None) hangs because the queue is full and there are no more workers consuming items in the queue (they exited early).

Increasing EXTRA_QUEUED_CALLS fixes the problem, though its probably not the correct solution.

----------
components: Library (Lib)
messages: 139541
nosy: pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: Hangs in concurrent.futures
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  1 07:25:40 2011
From: report at bugs.python.org (Peter Williams)
Date: Fri, 01 Jul 2011 05:25:40 +0000
Subject: [issue12457] type() returns incorrect type for nested classes
In-Reply-To: <1309497940.68.0.603392922196.issue12457@psf.upfronthosting.co.za>
Message-ID: <1309497940.68.0.603392922196.issue12457@psf.upfronthosting.co.za>


New submission from Peter Williams <pwil3058 at bigpond.net.au>:

The built in type() function returns incorrect type names for nested classes which in turn causes pickle to crash when used with nested classes as it cannot find the nested class definitions from the using the string returned by type().

e.g. if I have an instance "inner" of class Inner which is defined inside (nested in) the class Outer:

type(inner) returns <class '__main__.Inner'> instead of <class '__main__.Outer.Inner'>

The isinstance() function, as expected, returns True for isinstance(inner, Outer.Inner) and raises a NameError exception for isinstance(inner, Inner).

However, isinstance(inner, type(inner)) returns True which indicates the core functionality is OK and this conforms to the fact that no problems were encountered until I tried to pickle an object containing nested classes.

My system is Fedora 15 x86_64 and Python versions are 2.7.1 and 3.2.

A short program illustrating the problem is attached.

----------
components: None
files: nested_class_bug.py
messages: 139542
nosy: pwil3058
priority: normal
severity: normal
status: open
title: type() returns incorrect type for nested classes
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22531/nested_class_bug.py

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

From report at bugs.python.org  Fri Jul  1 07:32:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Jul 2011 05:32:09 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309498329.25.0.80389604221.issue8716@psf.upfronthosting.co.za>


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

Hold off on the buildbot changes for the moment.  I have an idea for a possible workaround/solution.

----------

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

From report at bugs.python.org  Fri Jul  1 07:46:47 2011
From: report at bugs.python.org (Petr Splichal)
Date: Fri, 01 Jul 2011 05:46:47 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
	lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>


New submission from Petr Splichal <psssssss at gmail.com>:

Currently, python tracebacks shows the last of continuation lines
when a function spans across multiple lines. This line usually
contains some function parameter only and thus is not very useful
for debugging the problem.

For example:

    Traceback (most recent call last):
    File "./tcms-run", line 48, in <module>
        summary=options.summary)
    File "/tmp/nitrate/Nitrate.py", line 600, in __init__
        raise NitrateError("Need either id or test plan")

If the traceback contained the beginning of the continuation line
it would be IMHO much more clear where/how the problem happened.

    Traceback (most recent call last):
    File "./tcms-run", line 48, in <module>
        run = TestRun(plan=plan, distro=options.distro,
    File "/tmp/nitrate/Nitrate.py", line 600, in __init__
        raise NitrateError("Need either id or test plan")

Version: Both Python 2 and Python 3.

Trivial reproducer:

    def fun1(par):
        raise Exception
    def fun2():
        fun1(
                par="value")
    fun2()

Actual results:

    Traceback (most recent call last):
    File "/tmp/traceback.py", line 10, in <module>
        fun2()
    File "/tmp/traceback.py", line 8, in fun2
        par="value")
    File "/tmp/traceback.py", line 4, in fun1
        raise Exception
    Exception

----------
components: Interpreter Core
messages: 139544
nosy: psss
priority: normal
severity: normal
status: open
title: Tracebacks should contain the first line of continuation lines
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul  1 07:49:09 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 01 Jul 2011 05:49:09 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309499349.27.0.725815068111.issue12456@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Further analysis seems to indicate that it is a race between the shutdown code and the processes finishing.

This code hangs:
"""
executor = concurrent.futures.ProcessPoolExecutor(2)
executor.map(is_prime, [1, 2])
executor.shutdown()
"""

while this doesn't:
"""
executor = concurrent.futures.ProcessPoolExecutor(2)
executor.map(is_prime, [1, 2])
time.sleep(1)
executor.shutdown()
"""

----------

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

From report at bugs.python.org  Fri Jul  1 08:09:22 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 01 Jul 2011 06:09:22 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309500562.29.0.91458288875.issue12455@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

AFAIR, that capitalize part is somewhere a requirement in RFC, if the server did not behave in proper manner, it may not be a good idea for the client to change (or be permissive the flag).

----------
nosy: +orsenthil

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

From report at bugs.python.org  Fri Jul  1 08:12:48 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 01 Jul 2011 06:12:48 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309500768.05.0.18634982657.issue12455@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sorry, not "Capitalize", but the "Title" part. One can some bugs which lead to this change in the urllib2.

----------

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

From report at bugs.python.org  Fri Jul  1 08:45:50 2011
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Fri, 01 Jul 2011 06:45:50 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt <eckhardt at satorlaser.com>:

For reference, see the thread on the users' mailinglist/newsgroup from 2011-06-29 "how to call a function for evry 10 seconds" and the thread on the developers' mailinglist from 2011-06-30 "time.sleep(-1) behaviour".

The problem is how negative arguments to time.sleep() are handled. Python 2.x (tested 2.5 and 2.7) implementations on MS Windows seems to have a 32-bit underflow while converting the given argument to the DWORD that is passed to win32's Sleep() function. This causes a small negative value to sleep for a long time.

On Linux, using Python 2.6, you get an IOError instead. While an error is better than blocking effectively forever, the use of an IOError to signal the wrong argument is at least confusing. I guess it is an artifact of the implementation, but that shouldn't be visible prominently.

IMHH, both versions should raise a ValueError to signal invalid arguments. However, there was also the suggestion to simply treat negative values as zero, after all time.sleep() is already documented to possibly sleep longer than specified.

----------
messages: 139548
nosy: eckhardt
priority: normal
severity: normal
status: open
title: time.sleep(-1.0) behaviour
type: behavior

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

From report at bugs.python.org  Fri Jul  1 09:13:20 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 01 Jul 2011 07:13:20 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309504400.94.0.794709408739.issue12450@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Amaury]
"It would be interesting to see if it is better/faster than the current dtoa."

I agree that it would be interesting to compare.

[Eric]
"maybe we can say we we can live with 99.5% shortest repr coverage"

Please no!  As you say, we'd still need the fallback code.

For me, a precondition for actually switching (rather than just investigating speed differences) would be that the Grisu3 code has excellent tests.  The dtoa.c code is still pretty hairy in places but is now fairly well tested and inspected;  I'd hesitate to replace that with something less well exercised.

----------

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

From report at bugs.python.org  Fri Jul  1 09:35:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jul 2011 07:35:42 +0000
Subject: [issue12457] type() returns incorrect type for nested classes
In-Reply-To: <1309497940.68.0.603392922196.issue12457@psf.upfronthosting.co.za>
Message-ID: <1309505742.73.0.951366981643.issue12457@psf.upfronthosting.co.za>


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

Inner classes can't be pickled (see the pickle docs for what can be pickled).

Whether or not there is a bug in the repr of the inner class is an interesting question.

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

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

From report at bugs.python.org  Fri Jul  1 09:45:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jul 2011 07:45:44 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1309506344.21.0.315862172375.issue12455@psf.upfronthosting.co.za>


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

Quoting http://tools.ietf.org/html/rfc2068#section-4.2:

  Field names are case-insensitive.

Which is only logical, since they are modeled on email headers, and email header names are case insensitive.  So, the server in question is broken, yes, but that doesn't mean we can't provide a facility to allow Python to inter-operate with it.  Email, for example, preserves the case of the field names it parses or receives from the application program, but otherwise treats them case-insensitively.  However, since the current code coerces to title case, we have to provide this feature as a switchable facility defaulting to the current behavior, for backward compatibility reasons.

And someone needs to write a patch....

----------

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

From report at bugs.python.org  Fri Jul  1 09:47:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Jul 2011 07:47:00 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309506420.29.0.88138459952.issue12459@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Fri Jul  1 09:55:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Jul 2011 07:55:40 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309506940.18.0.334707967276.issue12450@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Mark.  This is a very challenging area and no change would be warranted without keeping the current accuracy guarantees, definitive speed improvement, extensive tests, and consideration of the impact on users of having float reprs change yet again.

This was a nice tracker item for improving our awareness of alternate algorithms, but it isn't a credible feature request without the qualities listed above.  

I'll mark this as closed/rejected.  Feel free to reopen if we get some solid evidence that python would be significantly improved enough to warrant the disruption for users and the investment of developer time.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Fri Jul  1 10:24:28 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 01 Jul 2011 08:24:28 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309508668.54.0.296674418608.issue12442@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Agreed. 
New patch removes the percentage and fixes computations on posix as recommended by Charles-Fran?ois:

free = st.f_bavail * st.f_bsize
total = st.f_blocks * st.f_frsize
used = (total - st.f_bfree * st.f_bsize)

----------
Added file: http://bugs.python.org/file22532/diskusage3.patch

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

From report at bugs.python.org  Fri Jul  1 10:26:49 2011
From: report at bugs.python.org (Huzaifa Sidhpurwala)
Date: Fri, 01 Jul 2011 08:26:49 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1309508809.61.0.899940731871.issue11197@psf.upfronthosting.co.za>


Huzaifa Sidhpurwala <sidhpurwala.huzaifa at gmail.com> added the comment:

It seems python was being blamed for what is essentially the fault of lynx.

The following would translate into browsing files locally from the system and not from the web:

lynx http://localhost:8000/../../../../../../../../etc/passwd

The correct syntax for testing should have been:

lynx http://localhost:8000/../../../../../../../../etc/passwd

----------
nosy: +Huzaifa.Sidhpurwala

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

From report at bugs.python.org  Fri Jul  1 10:30:59 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Jul 2011 08:30:59 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1309509059.14.0.529687074055.issue12450@psf.upfronthosting.co.za>


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

Agreed. If some volunteer wants to work on it, I suggest to make an extension module first, so that everybody can try and compare with the current routines.

----------

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

From report at bugs.python.org  Fri Jul  1 10:35:01 2011
From: report at bugs.python.org (Huzaifa Sidhpurwala)
Date: Fri, 01 Jul 2011 08:35:01 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1309509301.83.0.389606055319.issue11197@psf.upfronthosting.co.za>


Huzaifa Sidhpurwala <sidhpurwala.huzaifa at gmail.com> added the comment:

This should have been

lynx localhost:8000/../../../../../../../../etc/passwd

v/s

lynx http://localhost:8000/../../../../../../../../etc/passwd

----------

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

From report at bugs.python.org  Fri Jul  1 11:31:28 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 01 Jul 2011 09:31:28 +0000
Subject: [issue12460] SocketServer.shutdown() does not have "timeout=None"
	parameter
In-Reply-To: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za>
Message-ID: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za>


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

Suppose i'm trying to correctly terminate thread with socketserver during application termination.

I do not want to wait too long (also do not want to hang), I want to protect against long-lived operations in SimpleServer

so something like
myserver.shutdown(2)
will be nice.

Also it should return True or False depending on successfull shutting down.

It's easy to implement - thanks to Threading.event.wait(timeout=...)

Don't know if it is applicable to python 3.x

----------
components: Library (Lib)
messages: 139557
nosy: mmarkk
priority: normal
severity: normal
status: open
title: SocketServer.shutdown() does not have "timeout=None" parameter
type: feature request
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jul  1 11:33:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 09:33:22 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309512802.82.0.767967162611.issue12459@psf.upfronthosting.co.za>


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

I think that time.sleep() should behave as select.select() (issue #11757, commit 3982be773b54) and signal.sigtimedwait(): raise a ValueError if the timeout is negative. A good reason to always raise an error is that floatsleep() has different implementations. Especially, the select() implementation behaves differently depending on the platform: negative timeout raises an error (select.error(22, 'Invalid argument')) or returns immediatly.

Attached patch raises an error if the time length is negative. It avoids the integer overflow in the Windows implementation.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file22533/sleep_negative.patch

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

From report at bugs.python.org  Fri Jul  1 11:34:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 09:34:21 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309512861.62.0.625383571513.issue12459@psf.upfronthosting.co.za>


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

I agree with the ValueError suggestion. Since it would slightly change existing behaviour, it can only be done in a feature release (3.3).

According to Google Code Search, deliberate uses of sleep(-1) are almost non-existent:
http://www.google.com/codesearch#search/&q=%22sleep%28-1%29%22%20lang:python&type=cs

----------
components: +Extension Modules
nosy: +pitrou
stage:  -> patch review
versions: +Python 3.3

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

From report at bugs.python.org  Fri Jul  1 11:41:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 09:41:52 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309513312.68.0.13321343461.issue12459@psf.upfronthosting.co.za>


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

> According to Google Code Search, deliberate uses of sleep(-1)
> are almost non-existent:

The search gives two results, in pycaf and a plone installer (in "compilezpy.py"). I don't know what is the expected behaviour: "infinite" sleep? wait for a SIGINT signal? I'm ok to only change this in Python 3.3, it's not a good idea to introduce subtle differences in minor Python releases.

----------

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

From report at bugs.python.org  Fri Jul  1 11:42:38 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 01 Jul 2011 09:42:38 +0000
Subject: [issue12461] it's not clear how the shutil.copystat() should work on
	symlinks
In-Reply-To: <1309513358.23.0.446931887968.issue12461@psf.upfronthosting.co.za>
Message-ID: <1309513358.23.0.446931887968.issue12461@psf.upfronthosting.co.za>


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

According to
http://hg.python.org/cpython/file/588fe0fc7160/Lib/shutil.py

it uses utimes(), stat() ans so on,
For some people, it's preferable to use lutimes() and lstat(),but for some people it's not.

For example, in old implementation, exception will raise on broken symlink during os.utime().

Also, copystat() does not check that chown can not be applied to a symlink.

I do not think that it's good to add two parameters like
shutil.copystat(src, dst, followsrc, followdst)

Adding just one parameter (followsymlinks) is not sufficient.

----------
components: Library (Lib)
messages: 139561
nosy: mmarkk
priority: normal
severity: normal
status: open
title: it's not clear how the shutil.copystat() should work on symlinks
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/issue12461>
_______________________________________

From report at bugs.python.org  Fri Jul  1 12:25:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 10:25:06 +0000
Subject: [issue12462] time.sleep(1): call PyErr_CheckSignals() if the sleep
	was interrupted
In-Reply-To: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>
Message-ID: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

While reading floatsleep() (time.sleep) code for issue #12459, I noticed that the Python signal handler is not called in floatsleep() if a signal interrupted the sleep. Well, it just "works" because the bytecode evaluation loop will call PyErr_CheckSignals() before executing the next instruction (the C signal handler signals calls Py_AddPendingCall whichs signals that the pending call to the eval loop using "eval_breaker"), but it would be better to call it directly.

Attached calls explicitly and immediatly PyErr_CheckSignals() in the sleep and Windows implementations of floatsleep().

It's not really a bug, so I prefer to not touch Python 2.7 and 3.2, only Python 3.3.

----------
components: Library (Lib)
files: sleep_signal.patch
keywords: patch
messages: 139562
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: time.sleep(1): call PyErr_CheckSignals() if the sleep was interrupted
versions: Python 3.3
Added file: http://bugs.python.org/file22534/sleep_signal.patch

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

From report at bugs.python.org  Fri Jul  1 12:26:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 10:26:15 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309515975.92.0.866910485671.issue12459@psf.upfronthosting.co.za>


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

See also #12462, I found something weird in the signal handling of floatsleep().

----------

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

From report at bugs.python.org  Fri Jul  1 12:28:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 10:28:04 +0000
Subject: [issue12462] time.sleep(1): call PyErr_CheckSignals() if the sleep
	was interrupted
In-Reply-To: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>
Message-ID: <1309516084.49.0.84073824545.issue12462@psf.upfronthosting.co.za>


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

You don't *need* to call PyErr_CheckSignals() explicitly, PyErr_SetFromErrno() does it for you.

----------

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

From report at bugs.python.org  Fri Jul  1 12:46:38 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 01 Jul 2011 10:46:38 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>


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

Why not to call self.__is_shut_down.set() in constructor ?

In reality, if event loop was not started, it mean that server is shut down.

----------
components: Library (Lib)
messages: 139565
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Calling SocketServer.shutdown() when server_forever() was not called will hang
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jul  1 12:46:42 2011
From: report at bugs.python.org (Hans Bering)
Date: Fri, 01 Jul 2011 10:46:42 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1309517202.76.0.304486525861.issue10647@psf.upfronthosting.co.za>


Hans Bering <hans.bering at arcor.de> added the comment:

I have been able to reproduce this problem with a current Python 3.2 + tcl/tk on Ubuntu. I have attached a script which should crash with the following output & stacktrace (you might have to find & set a suitable locale depending on your OS):

locale = ('de_DE', 'UTF8')
Traceback (most recent call last):
  File "tkinterCrash.py", line 20, in <module>
    tkcanvas = Canvas(master=master, width=w, height=2, borderwidth=4)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 2101, in __init__
    Widget.__init__(self, master, 'canvas', cnf, kw)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1961, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: bad screen distance "10.0"

The problem seems to stem from the fact that tkinter passes the "width" option through regardless of what it is (you can set w to the string "hello" to get the same error), and somewhere below (in tk, I guess?), the option argument is tentatively parsed as a number using the system's numeric locale.

Originally, we stumbled over this problem when using matplotlib, which passes/passed down float types as width arguments on occasions. It has been fixed there since (see https://github.com/matplotlib/matplotlib/pull/387).

It's the locale dependency which can make this difficult to debug when it occurs. In our setup, we had a program running on one machine, and then it crashed on the next, which we believed to have an identical setup; it took us a day to figure out what the difference was.

----------
nosy: +hans.bering
Added file: http://bugs.python.org/file22535/tkinterCrash.py

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

From report at bugs.python.org  Fri Jul  1 13:13:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 11:13:33 +0000
Subject: [issue12462] time.sleep(1): call PyErr_CheckSignals() if the sleep
	was interrupted
In-Reply-To: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>
Message-ID: <1309518813.57.0.645896858101.issue12462@psf.upfronthosting.co.za>


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

The sleep implementation of floatsleep() doesn't call PyErr_SetFromErrno() if errno is EINTR, whereas EINTR indicates that select() was interrupted. I agree that PyErr_CheckSignals() is overkill in the Windows implementation.

My new patch is more explicit: only add a special case for the select implementation, if errno is EINTR.

----------
Added file: http://bugs.python.org/file22536/sleep_signal-2.patch

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

From report at bugs.python.org  Fri Jul  1 13:47:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 11:47:36 +0000
Subject: [issue12462] time.sleep(1): call PyErr_CheckSignals() if the sleep
	was interrupted
In-Reply-To: <1309518813.57.0.645896858101.issue12462@psf.upfronthosting.co.za>
Message-ID: <1309520814.3644.0.camel@localhost.localdomain>


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

> My new patch is more explicit: only add a special case for the select
> implementation, if errno is EINTR.

Looks good to me!

----------

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

From report at bugs.python.org  Fri Jul  1 13:55:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 11:55:43 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <E1QccJx-0005Ac-RE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2fc102ebaf73 by Giampaolo Rodola' in branch 'default':
Issue #12442: add shutil.disk_usage()
http://hg.python.org/cpython/rev/2fc102ebaf73

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Jul  1 13:59:42 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 01 Jul 2011 11:59:42 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309521582.88.0.0260774735029.issue12442@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

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

From report at bugs.python.org  Fri Jul  1 14:19:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 12:19:32 +0000
Subject: [issue12462] time.sleep(1): call PyErr_CheckSignals() if the sleep
	was interrupted
In-Reply-To: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>
Message-ID: <E1Qcch0-0007lk-IA@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 583be15e22ca by Victor Stinner in branch 'default':
Issue #12462: time.sleep() now calls immediatly the (Python) signal handler if
http://hg.python.org/cpython/rev/583be15e22ca

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Jul  1 14:20:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 12:20:34 +0000
Subject: [issue12462] time.sleep(1): call PyErr_CheckSignals() if the sleep
	was interrupted
In-Reply-To: <1309515906.33.0.927447956049.issue12462@psf.upfronthosting.co.za>
Message-ID: <1309522834.31.0.488910126481.issue12462@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul  1 14:30:31 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 01 Jul 2011 12:30:31 +0000
Subject: [issue12460] SocketServer.shutdown() does not have "timeout=None"
	parameter
In-Reply-To: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za>
Message-ID: <1309523431.35.0.244314491256.issue12460@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/issue12460>
_______________________________________

From report at bugs.python.org  Fri Jul  1 14:30:45 2011
From: report at bugs.python.org (Evgeny Kapun)
Date: Fri, 01 Jul 2011 12:30:45 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>


New submission from Evgeny Kapun <abacabadabacaba at gmail.com>:

TemporaryDirectory.cleanup follows symbolic links to directories and tries to clean them as well. Try this (on Linux):

import os, tempfile
with tempfile.TemporaryDirectory() as d:
	os.symlink("/proc", d + "/test")

----------
components: Library (Lib)
messages: 139571
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory.cleanup follows symbolic links
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  1 14:43:55 2011
From: report at bugs.python.org (Evgeny Kapun)
Date: Fri, 01 Jul 2011 12:43:55 +0000
Subject: [issue12465] gc.get_referents can be used to crash Python
In-Reply-To: <1309524235.61.0.692133767187.issue12465@psf.upfronthosting.co.za>
Message-ID: <1309524235.61.0.692133767187.issue12465@psf.upfronthosting.co.za>


New submission from Evgeny Kapun <abacabadabacaba at gmail.com>:

This code crashes Python:

import gc
gc.get_referents(object.__dict__)[0].clear()
gc.get_referents(type.__dict__)[0].clear()
type("A", (), {})()

----------
components: Interpreter Core
messages: 139572
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: gc.get_referents can be used to crash Python
type: crash
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Jul  1 14:48:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 12:48:13 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309524493.62.0.845980102531.issue12459@psf.upfronthosting.co.za>


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

Tim Lesher on python-dev: "On the Windows side, Sleep(-1) as "infinite" is correct and documented:
http://msdn.microsoft.com/en-us/library/ms686298(v=vs.85).aspx"

Wine defines INFINITE using "#define INFINITE 0xFFFFFFFF":
http://source.winehq.org/source/include/winbase.h

-1 becomes INFINITE because of an integer overflow (because of a cast from double to *unsigned* long). time.sleep(-2) doesn't sleep for an infinite time, but for more than 136 years (maybe more in 64 bits?):

>>> print(datetime.timedelta(seconds=-2 & 0xFFFFFFFF))
49710 days, 6:28:14

What is the usecase of Sleep(INFINITE)? Wait a signal or wait another event?

Because other platforms don't support the INFINITE timeout, I suggest to always raise an error to have the same behaviour on all platforms. 

On POSIX, you can use pause(), sigwait(), select() or other functions to wait a signal for example. If we something something like that on Windows, we need a new function, but not a magic time.sleep(-1) please.

----------

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

From report at bugs.python.org  Fri Jul  1 14:53:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 12:53:42 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <E1QcdE5-00026a-CK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0ed5e6ff10f8 by Victor Stinner in branch '3.2':
Issue #11870: Skip test_threading.test_2_join_in_forked_process() on platforms
http://hg.python.org/cpython/rev/0ed5e6ff10f8

New changeset f43dee86fffd by Victor Stinner in branch 'default':
(merge 3.2) Issue #11870: Skip test_threading.test_2_join_in_forked_process()
http://hg.python.org/cpython/rev/f43dee86fffd

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Jul  1 14:56:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 12:56:22 +0000
Subject: [issue12466] test_subprocess.test_close_fds() sporadic failures on
	Mac OS X Tiger
In-Reply-To: <1309524982.22.0.267480095279.issue12466@psf.upfronthosting.co.za>
Message-ID: <1309524982.22.0.267480095279.issue12466@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
FAIL: test_close_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_subprocess.py", line 1302, in test_close_fds
    "Some fds were left open")
AssertionError: {9} is not false : Some fds were left open

http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2825/steps/test/logs/stdio

test_pass_fds() is already skipped on Mac OS X Tiger because of an OS bug: see issue #12230.

----------
messages: 139575
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_subprocess.test_close_fds() sporadic failures on Mac OS X Tiger

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

From report at bugs.python.org  Fri Jul  1 15:05:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 13:05:02 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <E1QcdP3-0003BA-6R@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ff36b8cadfd6 by Victor Stinner in branch '2.7':
Issue #11870: Skip test_threading.test_2_join_in_forked_process() on platforms
http://hg.python.org/cpython/rev/ff36b8cadfd6

----------

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

From report at bugs.python.org  Fri Jul  1 15:21:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 13:21:23 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
FAIL: test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_threading.py", line 677, in test_6_daemon_threads
    rc, out, err = assert_python_ok('-c', script)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\script_helper.py", line 50, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\script_helper.py", line 42, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 3, stderr follows:

Assertion failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c, line 501

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4881/steps/test/logs/stdio

----------
components: Library (Lib), Tests, Windows
messages: 139577
nosy: haypo
priority: normal
severity: normal
status: open
title: test_threading.test_6_daemon_threads(): Assertion failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c, line 501
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  1 15:21:38 2011
From: report at bugs.python.org (Cal Leeming)
Date: Fri, 01 Jul 2011 13:21:38 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309506344.21.0.315862172375.issue12455@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=ZrVhpPa7O3-GhfXZcJ2kDJV=x_g@mail.gmail.com>


Cal Leeming <cal.leeming at simplicitymedialtd.co.uk> added the comment:

Thats full understandable that the default won't change. I'll put this in my
todo list to write a patch in a week or two.
On 1 Jul 2011 08:45, "R. David Murray" <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Quoting http://tools.ietf.org/html/rfc2068#section-4.2:
>
> Field names are case-insensitive.
>
> Which is only logical, since they are modeled on email headers, and email
header names are case insensitive. So, the server in question is broken,
yes, but that doesn't mean we can't provide a facility to allow Python to
inter-operate with it. Email, for example, preserves the case of the field
names it parses or receives from the application program, but otherwise
treats them case-insensitively. However, since the current code coerces to
title case, we have to provide this feature as a switchable facility
defaulting to the current behavior, for backward compatibility reasons.
>
> And someone needs to write a patch....
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12455>
> _______________________________________

----------
nosy: +sleepycal
Added file: http://bugs.python.org/file22537/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________
-------------- next part --------------
<p>Thats full understandable that the default won&#39;t change. I&#39;ll put this in my todo list to write a patch in a week or two.</p>
<div class="gmail_quote">On 1 Jul 2011 08:45, &quot;R. David Murray&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br type="attribution">&gt; <br>&gt; R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
&gt; <br>&gt; Quoting <a href="http://tools.ietf.org/html/rfc2068#section-4.2">http://tools.ietf.org/html/rfc2068#section-4.2</a>:<br>&gt; <br>&gt;   Field names are case-insensitive.<br>&gt; <br>&gt; Which is only logical, since they are modeled on email headers, and email header names are case insensitive.  So, the server in question is broken, yes, but that doesn&#39;t mean we can&#39;t provide a facility to allow Python to inter-operate with it.  Email, for example, preserves the case of the field names it parses or receives from the application program, but otherwise treats them case-insensitively.  However, since the current code coerces to title case, we have to provide this feature as a switchable facility defaulting to the current behavior, for backward compatibility reasons.<br>
&gt; <br>&gt; And someone needs to write a patch....<br>&gt; <br>&gt; ----------<br>&gt; <br>&gt; _______________________________________<br>&gt; Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&gt; &lt;<a href="http://bugs.python.org/issue12455">http://bugs.python.org/issue12455</a>&gt;<br>&gt; _______________________________________<br></div>

From report at bugs.python.org  Fri Jul  1 15:26:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 13:26:04 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <E1QcdjO-00056U-Qk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8250f04d5a41 by Victor Stinner in branch '3.2':
Issue #12363: improve siginterrupt() tests
http://hg.python.org/cpython/rev/8250f04d5a41

----------

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

From report at bugs.python.org  Fri Jul  1 15:40:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 13:40:22 +0000
Subject: [issue12400] regrtest: always run tests in verbose mode,
	but hide the output on success
In-Reply-To: <1308948359.28.0.0557364005771.issue12400@psf.upfronthosting.co.za>
Message-ID: <1309527622.74.0.367567541854.issue12400@psf.upfronthosting.co.za>


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

Ok, no more regression / bug related to this issue, let close it.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul  1 15:44:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 13:44:20 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1309527860.47.0.49845421042.issue12231@psf.upfronthosting.co.za>


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

regrtest_regex-2.patch: minor update, just ensure that the patch applies correctly on the default branch.

----------
Added file: http://bugs.python.org/file22538/regrtest_regex-2.patch

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

From report at bugs.python.org  Fri Jul  1 16:00:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 14:00:02 +0000
Subject: [issue12363] test_signal.test_without_siginterrupt() sporadic
	failures on FreeBSD 6.4
In-Reply-To: <1308504105.8.0.100099791428.issue12363@psf.upfronthosting.co.za>
Message-ID: <E1QceGF-0007yf-Vk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3f30cfe51315 by Victor Stinner in branch '3.2':
Issue #12363: increase the timeout of siginterrupt() tests
http://hg.python.org/cpython/rev/3f30cfe51315

New changeset 423268537083 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12363: increase the timeout of siginterrupt() tests
http://hg.python.org/cpython/rev/423268537083

----------

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

From report at bugs.python.org  Fri Jul  1 16:06:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 14:06:49 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1303157880.98.0.834054534396.issue11870@psf.upfronthosting.co.za>
Message-ID: <1309529209.62.0.648936791245.issue11870@psf.upfronthosting.co.za>


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

The initial problem was test_3_join_in_forked_from_thread() and the hangs does still happen:

[324/356] test_threading
Timeout (1:00:00)!
Thread 0x404248c0:
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1498 in _communicate_with_poll
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1423 in _communicate
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 836 in communicate
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py", line 32 in _assert_python
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py", line 50 in assert_python_ok
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 434 in _run_and_join
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 493 in test_3_join_in_forked_from_thread
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 462 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 514 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 168 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1259 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1285 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 774 in test_main
  File "./Lib/test/regrtest.py", line 1070 in runtest_inner
  File "./Lib/test/regrtest.py", line 861 in runtest
  File "./Lib/test/regrtest.py", line 669 in main
  File "./Lib/test/regrtest.py", line 1648 in <module>

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/4081/steps/test/logs/stdio

(neologix's patch doesn't change anything for x86 Ubuntu Shared 3.x buildbot, which is a Linux, not a FreeBSD)

I don't know why it only hangs on this Linux buildbot. It's maybe an old Linux kernel, an old GNU libc version, or something like that?

----------

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

From report at bugs.python.org  Fri Jul  1 17:09:04 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 01 Jul 2011 15:09:04 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309532944.46.0.187887495339.issue12459@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/issue12459>
_______________________________________

From report at bugs.python.org  Fri Jul  1 17:23:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 15:23:47 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309443393.6.0.626834234358.issue6721@psf.upfronthosting.co.za>
Message-ID: <BANLkTineJU2aF-4mFv4QJoPK6izocnGECw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Well, I ping my view that we should:
>

Could you please detail the following points:
- what would be the API of this atfork() mechanism (with an example of
how it would be used in the library)?
- how do you find the correct order to acquire locks in the parent process?
- what do you do with locks that can be held for arbitrarily long
(e.g. I/O locks)?

----------

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

From report at bugs.python.org  Fri Jul  1 17:54:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 15:54:05 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <E1Qcg2c-0000uB-KM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f8ece8c93918 by R David Murray in branch '3.2':
#11873: fix test regex so it covers windows os.sep as well.
http://hg.python.org/cpython/rev/f8ece8c93918

New changeset e543c0ddec63 by R David Murray in branch 'default':
merge #11873: fix test regex so it covers windows os.sep as well.
http://hg.python.org/cpython/rev/e543c0ddec63

----------

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

From report at bugs.python.org  Fri Jul  1 17:55:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jul 2011 15:55:01 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1309535701.64.0.583472653748.issue11873@psf.upfronthosting.co.za>


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

Yeah, that's why I had reopened the issue...hopefully it is fixed now.

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

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

From report at bugs.python.org  Fri Jul  1 18:14:31 2011
From: report at bugs.python.org (Dan Sully)
Date: Fri, 01 Jul 2011 16:14:31 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1309536871.43.0.0922200898985.issue9253@psf.upfronthosting.co.za>


Changes by Dan Sully <dsully at gmail.com>:


----------
nosy: +dsully

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

From report at bugs.python.org  Fri Jul  1 18:25:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 16:25:56 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309537556.0.0.797929295979.issue12291@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/issue12291>
_______________________________________

From report at bugs.python.org  Fri Jul  1 18:26:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 16:26:04 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1309537564.06.0.0237793591018.issue12346@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/issue12346>
_______________________________________

From report at bugs.python.org  Fri Jul  1 18:34:53 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 01 Jul 2011 16:34:53 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309538093.08.0.237551314535.issue12459@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/issue12459>
_______________________________________

From report at bugs.python.org  Fri Jul  1 18:43:38 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 01 Jul 2011 16:43:38 +0000
Subject: [issue12457] type() returns incorrect type for nested classes
In-Reply-To: <1309497940.68.0.603392922196.issue12457@psf.upfronthosting.co.za>
Message-ID: <1309538618.14.0.946630196818.issue12457@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/issue12457>
_______________________________________

From report at bugs.python.org  Fri Jul  1 18:47:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 16:47:32 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309538852.12.0.844702530147.issue12456@psf.upfronthosting.co.za>


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

This patch should fix the issue. Can you confirm?

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file22539/cfshutdown.patch

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

From report at bugs.python.org  Fri Jul  1 18:49:57 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 01 Jul 2011 16:49:57 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1309538997.5.0.60588169595.issue12346@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/issue12346>
_______________________________________

From report at bugs.python.org  Fri Jul  1 18:50:53 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 01 Jul 2011 16:50:53 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1309539053.93.0.539673170414.issue12213@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/issue12213>
_______________________________________

From report at bugs.python.org  Fri Jul  1 18:51:00 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 01 Jul 2011 16:51:00 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1309539060.62.0.91001777282.issue12215@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/issue12215>
_______________________________________

From report at bugs.python.org  Fri Jul  1 18:55:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 16:55:20 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1309483032.63.0.796480334698.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309539278.26217.0.camel@localhost.localdomain>


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

Latest patch looks ok to me.

----------

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

From report at bugs.python.org  Fri Jul  1 19:21:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jul 2011 17:21:48 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1309540908.51.0.605682638612.issue11873@psf.upfronthosting.co.za>


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

I guess I'm just really bad at regexes.

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4885/steps/test/logs/stdio

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

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

From report at bugs.python.org  Fri Jul  1 19:34:08 2011
From: report at bugs.python.org (Kiril Mikos)
Date: Fri, 01 Jul 2011 17:34:08 +0000
Subject: [issue12468] longjmp causes uninitialized stack frame
In-Reply-To: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>
Message-ID: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>


New submission from Kiril Mikos <kiril.mik.os at gmail.com>:

*** longjmp causes uninitialized stack frame ***: /usr/bin/python2.7 terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2415de61d7]
/lib/x86_64-linux-gnu/libc.so.6(+0xfe169)[0x7f2415de6169]
/lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33)[0x7f2415de60d3]
/usr/lib/libcurl-gnutls.so.4(+0xbb45)[0x7f241528bb45]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfc60)[0x7f2416f11c60]
/lib/x86_64-linux-gnu/libpthread.so.0(sem_wait+0x30)[0x7f2416f0fea0]
/usr/bin/python2.7(PyThread_acquire_lock+0x11)[0x4aed31]
/usr/bin/python2.7[0x4afd3e]
/usr/bin/python2.7(PyEval_EvalFrameEx+0x361)[0x4965f1]
/usr/bin/python2.7(PyEval_EvalCodeEx+0x145)[0x49d325]
/usr/bin/python2.7(PyEval_EvalFrameEx+0x802)[0x496a92]
/usr/bin/python2.7(PyEval_EvalCodeEx+0x145)[0x49d325]
/usr/bin/python2.7(PyEval_EvalFrameEx+0x802)[0x496a92]
/usr/bin/python2.7(PyEval_EvalCodeEx+0x145)[0x49d325]
/usr/bin/python2.7[0x4c4526]
/usr/bin/python2.7(PyObject_Call+0x44)[0x45d864]
/usr/bin/python2.7[0x45f43f]
/usr/bin/python2.7[0x45b8ff]
/usr/bin/python2.7(PyObject_CallMethod+0xa8)[0x4c7e68]
/usr/bin/python2.7(Py_Finalize+0x4a)[0x42cf19]
/usr/bin/python2.7(Py_Main+0xb5d)[0x418d32]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xff)[0x7f2415d06eff]
/usr/bin/python2.7[0x4c62b1]
======= Memory map: ========
00400000-0062f000 r-xp 00000000 08:13 524506                             /usr/bin/python2.7
0082e000-0082f000 r--p 0022e000 08:13 524506                             /usr/bin/python2.7
0082f000-00897000 rw-p 0022f000 08:13 524506                             /usr/bin/python2.7
00897000-008a9000 rw-p 00000000 00:00 0 
02243000-024f3000 rw-p 00000000 00:00 0                                  [heap]
7f2408ffa000-7f2408ffb000 ---p 00000000 00:00 0 
7f2408ffb000-7f24097fb000 rw-p 00000000 00:00 0 
7f24097fb000-7f24097fc000 ---p 00000000 00:00 0 
7f24097fc000-7f2409ffc000 rw-p 00000000 00:00 0 
7f2409ffc000-7f2409ffd000 ---p 00000000 00:00 0 
7f2409ffd000-7f240a7fd000 rw-p 00000000 00:00 0 
7f240a7fd000-7f240a7fe000 ---p 00000000 00:00 0 
7f240a7fe000-7f240affe000 rw-p 00000000 00:00 0 
7f240affe000-7f240afff000 ---p 00000000 00:00 0 
7f240afff000-7f240b7ff000 rw-p 00000000 00:00 0 
7f240b7ff000-7f240b800000 ---p 00000000 00:00 0 
7f240b800000-7f240c000000 rw-p 00000000 00:00 0 
7f240c000000-7f240c047000 rw-p 00000000 00:00 0 
7f240c047000-7f2410000000 ---p 00000000 00:00 0 
7f24100fb000-7f2410110000 r-xp 00000000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f2410110000-7f241030f000 ---p 00015000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f241030f000-7f2410310000 r--p 00014000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f2410310000-7f2410311000 rw-p 00015000 08:13 1317460                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f2410311000-7f2410352000 rw-p 00000000 00:00 0 
7f2410352000-7f2410353000 ---p 00000000 00:00 0 
7f2410353000-7f2410b53000 rw-p 00000000 00:00 0 
7f2410b53000-7f2410b54000 ---p 00000000 00:00 0 
7f2410b54000-7f2411354000 rw-p 00000000 00:00 0 
7f2411354000-7f2411355000 ---p 00000000 00:00 0 
7f2411355000-7f2411b55000 rw-p 00000000 00:00 0 
7f2411b55000-7f2411b56000 ---p 00000000 00:00 0 
7f2411b56000-7f2412458000 rw-p 00000000 00:00 0 
7f2412458000-7f241247f000 r-xp 00000000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f241247f000-7f241267f000 ---p 00027000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f241267f000-7f2412681000 r--p 00027000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f2412681000-7f2412682000 rw-p 00029000 08:13 1317525                    /lib/x86_64-linux-gnu/libexpat.so.1.5.2
7f2412682000-7f2412691000 r-xp 00000000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412691000-7f2412890000 ---p 0000f000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412890000-7f2412891000 r--p 0000e000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412891000-7f2412893000 rw-p 0000f000 08:13 538071                     /usr/lib/python2.7/lib-dynload/pyexpat.so
7f2412893000-7f24128a6000 r-xp 00000000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f24128a6000-7f2412aa6000 ---p 00013000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f2412aa6000-7f2412aa7000 r--p 00013000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f2412aa7000-7f2412aab000 rw-p 00014000 08:13 538046                     /usr/lib/python2.7/lib-dynload/datetime.so
7f2412aab000-7f2412aec000 rw-p 00000000 00:00 0 
7f2412aec000-7f2412b09000 r-xp 00000000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412b09000-7f2412d08000 ---p 0001d000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412d08000-7f2412d09000 r--p 0001c000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412d09000-7f2412d12000 rw-p 0001d000 08:13 538049                     /usr/lib/python2.7/lib-dynload/_io.so
7f2412d12000-7f2412d53000 rw-p 00000000 00:00 0 
7f2412d53000-7f2412d56000 r-xp 00000000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412d56000-7f2412f55000 ---p 00003000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412f55000-7f2412f56000 r--p 00002000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412f56000-7f2412f58000 rw-p 00003000 08:13 538048                     /usr/lib/python2.7/lib-dynload/_heapq.so
7f2412f58000-7f2412f67000 r-xp 00000000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2412f67000-7f2413167000 ---p 0000f000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2413167000-7f2413168000 r--p 0000f000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2413168000-7f2413169000 rw-p 00010000 08:13 527185                     /usr/lib/x86_64-linux-gnu/libtasn1.so.3.1.9
7f2413169000-7f241316b000 r-xp 00000000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241316b000-7f241336a000 ---p 00002000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241336a000-7f241336b000 r--p 00001000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241336b000-7f241336c000 rw-p 00002000 08:13 1320416                    /lib/x86_64-linux-gnu/libkeyutils.so.1.3
7f241336c000-7f2413373000 r-xp 00000000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413373000-7f2413572000 ---p 00007000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413572000-7f2413573000 r--p 00006000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413573000-7f2413574000 rw-p 00007000 08:13 526951                     /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f2413574000-7f2413577000 r-xp 00000000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413577000-7f2413776000 ---p 00003000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413776000-7f2413777000 r--p 00002000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413777000-7f2413778000 rw-p 00003000 08:13 1320411                    /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f2413778000-7f241379d000 r-xp 00000000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241379d000-7f241399d000 ---p 00025000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241399d000-7f241399e000 r--p 00025000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241399e000-7f241399f000 rw-p 00026000 08:13 527485                     /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f241399f000-7f2413a59000 r-xp 00000000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413a59000-7f2413c59000 ---p 000ba000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413c59000-7f2413c62000 r--p 000ba000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413c62000-7f2413c63000 rw-p 000c3000 08:13 527489                     /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f2413c63000-7f2413c7c000 r-xp 00000000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413c7c000-7f2413e7b000 ---p 00019000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413e7b000-7f2413e7c000 r--p 00018000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413e7c000-7f2413e7d000 rw-p 00019000 08:13 533107                     /usr/lib/libsasl2.so.2.0.23
7f2413e7d000-7f2413e94000 r-xp 00000000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2413e94000-7f2414094000 ---p 00017000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2414094000-7f2414095000 r--p 00017000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2414095000-7f2414096000 rw-p 00018000 08:13 1317029                    /lib/x86_64-linux-gnu/libresolv-2.13.so
7f2414096000-7f2414098000 rw-p 00000000 00:00 0 
7f2414098000-7f241409b000 r-xp 00000000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241409b000-7f241429a000 ---p 00003000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241429a000-7f241429b000 r--p 00002000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241429b000-7f241429c000 rw-p 00003000 08:13 1320378                    /lib/x86_64-linux-gnu/libgpg-error.so.0.8.0
7f241429c000-7f2414336000 r-xp 00000000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f2414336000-7f2414536000 ---p 0009a000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f2414536000-7f241453c000 r--p 0009a000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f241453c000-7f241453d000 rw-p 000a0000 08:13 527680                     /usr/lib/x86_64-linux-gnu/libgnutls.so.26.14.12
7f241453d000-7f2414570000 r-xp 00000000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414570000-7f2414770000 ---p 00033000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414770000-7f2414771000 r--p 00033000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414771000-7f2414772000 rw-p 00034000 08:13 527487                     /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f2414772000-7f2414779000 r-xp 00000000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f2414779000-7f2414978000 ---p 00007000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f2414978000-7f2414979000 r--p 00006000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f2414979000-7f241497a000 rw-p 00007000 08:13 1317030                    /lib/x86_64-linux-gnu/librt-2.13.so
7f241497a000-7f24149c1000 r-xp 00000000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f24149c1000-7f2414bc0000 ---p 00047000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f2414bc0000-7f2414bc2000 r--p 00046000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f2414bc2000-7f2414bc3000 rw-p 00048000 08:13 527911                     /usr/lib/libldap_r-2.4.so.2.5.6
7f2414bc3000-7f2414bc5000 rw-p 00000000 00:00 0 
7f2414bc5000-7f2414bd2000 r-xp 00000000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414bd2000-7f2414dd1000 ---p 0000d000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414dd1000-7f2414dd2000 r--p 0000c000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414dd2000-7f2414dd3000 rw-p 0000d000 08:13 533112                     /usr/lib/liblber-2.4.so.2.5.6
7f2414dd3000-7f2414e04000 r-xp 00000000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2414e04000-7f2415004000 ---p 00031000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2415004000-7f2415005000 r--p 00031000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2415005000-7f2415006000 rw-p 00032000 08:13 524380                     /usr/lib/libidn.so.11.6.1
7f2415006000-7f241507c000 r-xp 00000000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f241507c000-7f241527c000 ---p 00076000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f241527c000-7f241527d000 r--p 00076000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f241527d000-7f2415280000 rw-p 00077000 08:13 1320380                    /lib/x86_64-linux-gnu/libgcrypt.so.11.6.0
7f2415280000-7f24152d2000 r-xp 00000000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24152d2000-7f24154d1000 ---p 00052000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24154d1000-7f24154d3000 r--p 00051000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24154d3000-7f24154d4000 rw-p 00053000 08:13 530086                     /usr/lib/libcurl-gnutls.so.4.2.0
7f24154d4000-7f24154e3000 r-xp 00000000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24154e3000-7f24156e2000 ---p 0000f000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24156e2000-7f24156e3000 r--p 0000e000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24156e3000-7f24156e5000 rw-p 0000f000 08:13 1189747                    /usr/lib/pyshared/python2.7/pycurl.so
7f24156e5000-7f2415ae2000 r--p 00000000 08:13 524688                     /usr/lib/locale/locale-archive
7f2415ae2000-7f2415ae6000 r-xp 00000000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ae6000-7f2415ce5000 ---p 00004000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ce5000-7f2415ce6000 r--p 00003000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ce6000-7f2415ce8000 rw-p 00004000 08:13 538064                     /usr/lib/python2.7/lib-dynload/termios.so
7f2415ce8000-7f2415e72000 r-xp 00000000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2415e72000-7f2416071000 ---p 0018a000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2416071000-7f2416075000 r--p 00189000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2416075000-7f2416076000 rw-p 0018d000 08:13 1317014                    /lib/x86_64-linux-gnu/libc-2.13.so
7f2416076000-7f241607c000 rw-p 00000000 00:00 0 
7f241607c000-7f2416100000 r-xp 00000000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f2416100000-7f24162ff000 ---p 00084000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f24162ff000-7f2416300000 r--p 00083000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f2416300000-7f2416301000 rw-p 00084000 08:13 1317018                    /lib/x86_64-linux-gnu/libm-2.13.so
7f2416301000-7f2416318000 r-xp 00000000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416318000-7f2416517000 ---p 00017000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416517000-7f2416518000 r--p 00016000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416518000-7f2416519000 rw-p 00017000 08:13 1317381                    /lib/x86_64-linux-gnu/libz.so.1.2.3.4
7f2416519000-7f241667f000 r-xp 00000000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f241667f000-7f241687f000 ---p 00166000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f241687f000-7f241688c000 r--p 00166000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f241688c000-7f24168a5000 rw-p 00173000 08:13 922820                     /lib/libcrypto.so.0.9.8
7f24168a5000-7f24168a8000 rw-p 00000000 00:00 0 
7f24168a8000-7f24168f4000 r-xp 00000000 08:13 922821                     /lib/libssl.so.0.9.8
7f24168f4000-7f2416af4000 ---p 0004c000 08:13 922821                     /lib/libssl.so.0.9.8
7f2416af4000-7f2416af5000 r--p 0004c000 08:13 922821                     /lib/libssl.so.0.9.8
7f2416af5000-7f2416afb000 rw-p 0004d000 08:13 922821                     /lib/libssl.so.0.9.8
7f2416afb000-7f2416afd000 r-xp 00000000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416afd000-7f2416cfc000 ---p 00002000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416cfc000-7f2416cfd000 r--p 00001000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416cfd000-7f2416cfe000 rw-p 00002000 08:13 1317033                    /lib/x86_64-linux-gnu/libutil-2.13.so
7f2416cfe000-7f2416d00000 r-xp 00000000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416d00000-7f2416f00000 ---p 00002000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416f00000-7f2416f01000 r--p 00002000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416f01000-7f2416f02000 rw-p 00003000 08:13 1317017                    /lib/x86_64-linux-gnu/libdl-2.13.so
7f2416f02000-7f2416f1a000 r-xp 00000000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f2416f1a000-7f241711a000 ---p 00018000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f241711a000-7f241711b000 r--p 00018000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f241711b000-7f241711c000 rw-p 00019000 08:13 1317028                    /lib/x86_64-linux-gnu/libpthread-2.13.so
7f241711c000-7f2417120000 rw-p 00000000 00:00 0 
7f2417120000-7f2417141000 r-xp 00000000 08:13 1317011                    /lib/x86_64-linux-gnu/ld-2.13.so
7f241715d000-7f2417261000 rw-p 00000000 00:00 0 
7f2417293000-7f241731a000 rw-p 00000000 00:00 0 
7f2417339000-7f241733a000 rw-p 00000000 00:00 0 
7f241733c000-7f2417340000 rw-p 00000000 00:00 0 
7f2417340000-7f2417341000 r--p 00020000 08:13 1317011                    /lib/x86_64-linux-gnu/ld-2.13.so
7f2417341000-7f2417343000 rw-p 00021000 08:13 1317011                    /lib/x86_64-linux-gnu/ld-2.13.so
7fff510e6000-7fff51107000 rw-p 00000000 00:00 0                          [stack]
7fff511ff000-7fff51200000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Modules used:
import pycurl
import os
import ConfigParser
import re
import xmlrpclib
import urllib2
import Queue
import threading

----------
components: Interpreter Core
messages: 139590
nosy: mik_os
priority: normal
severity: normal
status: open
title: longjmp causes uninitialized stack frame
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  1 19:36:37 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 01 Jul 2011 17:36:37 +0000
Subject: [issue12468] longjmp causes uninitialized stack frame
In-Reply-To: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>
Message-ID: <1309541797.56.0.765023079952.issue12468@psf.upfronthosting.co.za>


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

Do you have a python code snippet which triggers this?

----------
nosy: +eric.smith

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

From report at bugs.python.org  Fri Jul  1 19:48:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jul 2011 17:48:39 +0000
Subject: [issue12460] SocketServer.shutdown() does not have "timeout=None"
	parameter
In-Reply-To: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za>
Message-ID: <1309542519.59.0.149103305139.issue12460@psf.upfronthosting.co.za>


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

Well, it's not applicable to 2.x, since it is a feature request.  As such it could only go into 3.3.  I don't have an opinion on the merits of the suggestion.

----------
nosy: +r.david.murray
versions: +Python 3.3 -Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Jul  1 19:49:45 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 01 Jul 2011 17:49:45 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309542585.09.0.907658116664.issue12459@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

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

From report at bugs.python.org  Fri Jul  1 19:50:21 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 01 Jul 2011 17:50:21 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1309542621.65.0.822947697117.issue12463@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

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

From report at bugs.python.org  Fri Jul  1 19:52:48 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 01 Jul 2011 17:52:48 +0000
Subject: [issue12460] SocketServer.shutdown() does not have "timeout=None"
	parameter
In-Reply-To: <1309512688.11.0.74406934883.issue12460@psf.upfronthosting.co.za>
Message-ID: <1309542768.74.0.377650456901.issue12460@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

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

From report at bugs.python.org  Fri Jul  1 20:11:14 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 01 Jul 2011 18:11:14 +0000
Subject: [issue12468] longjmp causes uninitialized stack frame
In-Reply-To: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>
Message-ID: <1309543874.83.0.499397943523.issue12468@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/issue12468>
_______________________________________

From report at bugs.python.org  Fri Jul  1 20:45:30 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 01 Jul 2011 18:45:30 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309545930.1.0.843072915725.issue12456@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Yes, the patch does appear to fix the issue.

Thanks

----------

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

From report at bugs.python.org  Fri Jul  1 20:54:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 18:54:03 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1309546443.48.0.429064975027.issue12213@psf.upfronthosting.co.za>


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


----------
priority: normal -> critical
type:  -> behavior

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

From report at bugs.python.org  Fri Jul  1 20:57:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 18:57:39 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <E1QciuH-0007XT-19@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6fdb1f000d36 by R David Murray in branch '3.2':
#11873: another try at fixing the regex, courtesy of Victor Stinner
http://hg.python.org/cpython/rev/6fdb1f000d36

New changeset 775356b583d1 by R David Murray in branch 'default':
merge #11873: another try at fixing the regex, courtesy of Victor Stinner
http://hg.python.org/cpython/rev/775356b583d1

----------

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

From report at bugs.python.org  Fri Jul  1 21:28:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 19:28:16 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_faulthandler fails on the FreeBSD 6 buildbot since my commit 024827a9db64990865d29f9d525694f51197e770:

Issue #12392: fix thread initialization on FreeBSD 6

On FreeBSD6, pthread_kill() doesn't work on the main thread before the creation
of the first thread. Create therefore a dummy thread (no-op) a startup to
initialize the pthread library.

Add also a test for this use case, test written by Charles-Fran?ois Natali.

----------
components: Library (Lib)
messages: 139595
nosy: haypo
priority: normal
severity: normal
status: open
title: test_faulthandler failures on FreeBSD 6
versions: Python 3.3

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

From report at bugs.python.org  Fri Jul  1 21:29:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 19:29:03 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <1309548543.72.0.802074977148.issue12392@psf.upfronthosting.co.za>


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

This issue introduced regressions in the faulthandler module: see issue #12469.

----------

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

From report at bugs.python.org  Fri Jul  1 21:29:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 19:29:16 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309548556.42.0.463268815709.issue12469@psf.upfronthosting.co.za>


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


----------
nosy: +neologix

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

From report at bugs.python.org  Fri Jul  1 21:41:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jul 2011 19:41:42 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1309549302.39.0.705190738458.issue11873@psf.upfronthosting.co.za>


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

I'm going to be an optimist and close this again.

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

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

From report at bugs.python.org  Fri Jul  1 21:48:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 19:48:48 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309549728.18.0.719453770031.issue12469@psf.upfronthosting.co.za>


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

Debug session with gdb:
-----------------------------------------------
[vstinner at buildbot-freebsd ~/cpython]$ gdb -args ./python x.py 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...run

(gdb) run
Starting program: /usr/home/vstinner/cpython/python x.py
warning: Unable to get location for thread creation breakpoint: generic error
[New LWP 100106]
[New Thread 0x81f8000 (LWP 100089)]

Program received signal SIGBUS, Bus error.
[Switching to Thread 0x81f8000 (LWP 100083)]
stack_overflow (min_sp=0xb97fe7f0, max_sp=0xc5ffe7f0, depth=0xbfbfe7f0)
    at ./Modules/faulthandler.c:870
870	    buffer[0] = 1;
(gdb) signal SIGBUS
Continuing with signal SIGBUS.
[New LWP 100083]

Program received signal SIGBUS, Bus error.
[Switching to LWP 100083]
0x2824df2a in signalcontext () from /lib/libc.so.6
(gdb) handle SIGBUS nostop
Signal        Stop	Print	Pass to program	Description
SIGBUS        No	Yes	Yes		Bus error
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/home/vstinner/cpython/python x.py
warning: Unable to get location for thread creation breakpoint: generic error
[New LWP 100096]
[New Thread 0x81f8000 (LWP 100096)]

Program received signal SIGBUS, Bus error.
[New LWP 100096]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
-----------------------------------------------

If I revert the commit, faulthandler is able to dump the traceback on a stack overflow. But if I create a thread (and wait until it exits), faulthandler signal handler (for SIGBUS) is no more called.

----------

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

From report at bugs.python.org  Fri Jul  1 21:50:55 2011
From: report at bugs.python.org (Nir Aides)
Date: Fri, 01 Jul 2011 19:50:55 +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: <1309549855.08.0.771144996469.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> - what would be the API of this atfork() mechanism (with an example of how it would be used in the library)?

The atfork API is defined in POSIX and Gregory P. Smith proposed a Python one above that we can look into.
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html

We may need an API to reset a lock.

> - how do you find the correct order to acquire locks in the parent process?

One option is to use the import graph to determine call order of atfork handlers. 
If a current std library does not fit into this scheme we can possibly fix it when writing its handlers.

> - what do you do with locks that can be held for arbitrarily long (e.g. I/O locks)?

It is likely that such a lock does not need acquiring at the parent, and re-initializing the library in the child handler will do.
A  "critical section" lock that protects in-memory data should not be held for long.

----------

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

From report at bugs.python.org  Fri Jul  1 21:58:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 19:58:41 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309550321.38.0.286082388223.issue12469@psf.upfronthosting.co.za>


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

By the way, the failures:

Re-running test 'test_faulthandler' in verbose mode
test_disable (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_traceback (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_traceback_file (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_traceback_threads (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_traceback_threads_file (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_tracebacks_later (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_tracebacks_later_cancel (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_tracebacks_later_file (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_tracebacks_later_repeat (test.test_faulthandler.FaultHandlerTests) ... ok
test_dump_tracebacks_later_twice (test.test_faulthandler.FaultHandlerTests) ... ok
test_enable_file (test.test_faulthandler.FaultHandlerTests) ... ok
test_enable_single_thread (test.test_faulthandler.FaultHandlerTests) ... ok
test_fatal_error (test.test_faulthandler.FaultHandlerTests) ... ok
test_gil_released (test.test_faulthandler.FaultHandlerTests) ... ok
test_is_enabled (test.test_faulthandler.FaultHandlerTests) ... ok
test_read_null (test.test_faulthandler.FaultHandlerTests) ... ok
test_register (test.test_faulthandler.FaultHandlerTests) ... ok
test_register_file (test.test_faulthandler.FaultHandlerTests) ... FAIL
test_register_threads (test.test_faulthandler.FaultHandlerTests) ... FAIL
test_sigabrt (test.test_faulthandler.FaultHandlerTests) ... ok
test_sigbus (test.test_faulthandler.FaultHandlerTests) ... ok
test_sigfpe (test.test_faulthandler.FaultHandlerTests) ... ok
test_sigill (test.test_faulthandler.FaultHandlerTests) ... ok
test_sigsegv (test.test_faulthandler.FaultHandlerTests) ... ok
test_stack_overflow (test.test_faulthandler.FaultHandlerTests) ... FAIL
test_unregister (test.test_faulthandler.FaultHandlerTests) ... ok

======================================================================
FAIL: test_register (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 498, in test_register
    self.check_register()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 489, in check_register
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Traceback \\(most recent call first\\):\n  File "<string>", line 6 in func\n  File "<string>", line 17 in <module>$' not found in 'Traceback (most recent call first):'

======================================================================
FAIL: test_register_file (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 505, in test_register_file
    self.check_register(filename=filename)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 489, in check_register
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Traceback \\(most recent call first\\):\n  File "<string>", line 6 in func\n  File "<string>", line 17 in <module>$' not found in 'Traceback (most recent call first):\n  File "<string>", line 19 in <module>'

======================================================================
FAIL: test_register_threads (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 508, in test_register_threads
    self.check_register(all_threads=True)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 489, in check_register
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Current thread XXX:\n  File "<string>", line 6 in func\n  File "<string>", line 17 in <module>$' not found in 'Current thread XXX:'

======================================================================
FAIL: test_stack_overflow (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 185, in test_stack_overflow
    other_regex='unable to raise a stack overflow')
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_faulthandler.py", line 104, in check_fatal_error
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 3 in <module>$|unable to raise a stack overflow' not found in ''

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

----------

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

From report at bugs.python.org  Fri Jul  1 22:44:08 2011
From: report at bugs.python.org (Alan Hourihane)
Date: Fri, 01 Jul 2011 20:44:08 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1309553048.52.0.169655256509.issue10898@psf.upfronthosting.co.za>


Alan Hourihane <alanh at fairlite.co.uk> added the comment:

Hi Antoine,

Unfortunately the #undef is too early and later #includes redefine it.

We should move the #undef closer to the code that actually uses them.

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

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

From report at bugs.python.org  Fri Jul  1 22:48:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 20:48:47 +0000
Subject: [issue11870] test_3_join_in_forked_from_thread() of test_threading
	hangs 1 hour on "x86 Ubuntu Shared 3.x"
In-Reply-To: <1309529209.62.0.648936791245.issue11870@psf.upfronthosting.co.za>
Message-ID: <BANLkTik1qP9X619kdOX6McVLvQG0154kjA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The initial problem was test_3_join_in_forked_from_thread() and the hangs does still happen:
>

Yes, the patch was there to fix test_2_join_in_forked_from_thread.

> [324/356] test_threading
> Timeout (1:00:00)!
> Thread 0x404248c0:
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1498 in _communicate_with_poll
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1423 in _communicate
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 836 in communicate
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py", line 32 in _assert_python
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py", line 50 in assert_python_ok
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 434 in _run_and_join
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 493 in test_3_join_in_forked_from_thread
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 407 in _executeTestPart
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 462 in run
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 514 in __call__
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 105 in run
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 67 in __call__
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 168 in run
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1259 in _run_suite
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support.py", line 1285 in run_unittest
> ?File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py", line 774 in test_main
> ?File "./Lib/test/regrtest.py", line 1070 in runtest_inner
> ?File "./Lib/test/regrtest.py", line 861 in runtest
> ?File "./Lib/test/regrtest.py", line 669 in main
> ?File "./Lib/test/regrtest.py", line 1648 in <module>
>
> http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/4081/steps/test/logs/stdio
>

This means that the subprocess hangs, but without a backtrace of the
child process (issue #12413), it's hard to analyse it further.
I've had a look at the code, and couldn't find anything obviously
wrong; Gregory's patches to sanitize threading's lock should have
fixed this. I also tried running this test in a loop for 48 hours but
couldn't reproduce it.
One possible explanation (but it's just a wild guess) is that with a
certain kernel/libc configuration, the lock deallocation code can
deadlock (I've seen pthread_cond_destroy() block, this could maybe
happen with sem_destroy()).

So I suggest to try to come up with a solution to #12413, which should
help analyzing this - and similar - issues.

----------

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

From report at bugs.python.org  Fri Jul  1 22:52:17 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 01 Jul 2011 20:52:17 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1309553537.84.0.0875257624083.issue12191@psf.upfronthosting.co.za>


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

I've applied some of the suggestions Victor made (and also refresh to be cleanly applicable on default).

----------
Added file: http://bugs.python.org/file22540/shutil_chown-default-v4.patch

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

From report at bugs.python.org  Fri Jul  1 22:56:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jul 2011 20:56:48 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <E1Qcklb-0000Bx-5W@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 45b27448f95c by Antoine Pitrou in branch '2.7':
Really fix issue #10898: posixmodule.c redefines FSTAT
http://hg.python.org/cpython/rev/45b27448f95c

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Jul  1 22:57:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 20:57:42 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1309553862.49.0.499324179381.issue10898@psf.upfronthosting.co.za>


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

Ah, sorry. Can you check with the changeset I've just pushed (it's on branch 2.7)?
If ok, I'll port it to 3.2/3.x and close again.

----------
resolution: accepted -> fixed

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

From report at bugs.python.org  Fri Jul  1 23:02:33 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 01 Jul 2011 21:02:33 +0000
Subject: [issue12470] Fix cut&paste typo in test_shutil
In-Reply-To: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>
Message-ID: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>


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

There is a cut & paste typo in test_shutil file, this patch fixes it.

----------
components: Tests
files: shutil_tests_cut_paste_typo.patch
keywords: patch
messages: 139606
nosy: sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Fix cut&paste typo in test_shutil
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22541/shutil_tests_cut_paste_typo.patch

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

From report at bugs.python.org  Fri Jul  1 23:05:18 2011
From: report at bugs.python.org (Renaud Blanch)
Date: Fri, 01 Jul 2011 21:05:18 +0000
Subject: [issue12471] wrong TypeError message on '%i' formatting
In-Reply-To: <1309554318.72.0.913120070593.issue12471@psf.upfronthosting.co.za>
Message-ID: <1309554318.72.0.913120070593.issue12471@psf.upfronthosting.co.za>


New submission from Renaud Blanch <rndblnch at gmail.com>:

The TypeError message is erroneous when attempting to format a non number object with a '%i' string (notice the '%d' in the error message):

    >>> '%i' % 's'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: %d format: a number is required, not str

This is because PyUnicode_Format aliases i to d for the formatting handling, but this has the side effect of performing the substitution in the error message too.

The attached patch (against 3.3, but this behaviour has been there since 2.6) suppress the side effect and corrects the error message.

----------
components: Interpreter Core
files: PyUnicode_Format_TypeError_message.patch
keywords: patch
messages: 139607
nosy: rndblnch
priority: normal
severity: normal
status: open
title: wrong TypeError message on '%i' formatting
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22542/PyUnicode_Format_TypeError_message.patch

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

From report at bugs.python.org  Fri Jul  1 23:09:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 21:09:06 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309549855.08.0.771144996469.issue6721@psf.upfronthosting.co.za>
Message-ID: <BANLkTikhL7_f+rbw99FrXaHc+-YPgZz6SQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>> - how do you find the correct order to acquire locks in the parent process?
>
> One option is to use the import graph to determine call order of atfork handlers.
> If a current std library does not fit into this scheme we can possibly fix it when writing its handlers.
>

Sorry, I fail to see how the "import graph" is related to the correct
lock acquisition order. Some locks are created dynamically, for
example.
That's why I asked for a specific API: when do you register a handler?
When are they called? When are they reset?

>> - what do you do with locks that can be held for arbitrarily long (e.g. I/O locks)?
>
> It is likely that such a lock does not need acquiring at the parent, and re-initializing the library in the child handler will do.

The whole point of atfork is to avoid breaking invariants and
introduce invalid state in the child process. If there is one thing we
want to avoid, it's precisely reading/writting corrupted data from/to
files, so eluding the I/O problem seems foolish to me.

> A ?"critical section" lock that protects in-memory data should not be held for long.

Not necessarily. See for example I/O locks and logging module, which
hold locks until I/O completion.

----------

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

From report at bugs.python.org  Fri Jul  1 23:29:46 2011
From: report at bugs.python.org (kais58)
Date: Fri, 01 Jul 2011 21:29:46 +0000
Subject: [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>


New submission from kais58 <kais58 at sucs.org>:

I'm trying to build Python 2.7.2 on IRIX 6.5.30 and get the attached error in ./Modules/signalmodule.c

----------
components: None
files: error.txt
messages: 139609
nosy: kais58
priority: normal
severity: normal
status: open
title: Build failure on IRIX
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file22543/error.txt

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

From report at bugs.python.org  Fri Jul  1 23:49:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 21:49:50 +0000
Subject: [issue12468] longjmp causes uninitialized stack frame
In-Reply-To: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>
Message-ID: <1309556990.34.0.134695489363.issue12468@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

longjmp() is used in only two places:

./Modules/fpectlmodule.c:        longjmp(PyFPE_jbuf, 1);
./Modules/readline.c:    longjmp(jbuf, 1);

Both use it to jump out of a signal handler, which can lead to undefined behaviour (see https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp()+from+inside+a+signal+handler).
Now, there are two reasons for this behaviour:
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2415de61d7]
/lib/x86_64-linux-gnu/libc.so.6(+0xfe169)[0x7f2415de6169]
/lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33)[0x7f2415de60d3]

see the __longjmp_chk and __fortify_fail?
That means that Python's been compiled with gcc -D_FORTIFY_SOURCE option option, and the runtime check probably detects this and aborts the program (and the fact that it's a multi-threaded application probably.

The other reason is that it's a multi-threaded application, so if you end up doing a longjmp and restore the environment saved by another thread, you're screwed.

----------
nosy: +neologix

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

From report at bugs.python.org  Fri Jul  1 23:52:05 2011
From: report at bugs.python.org (Alan Hourihane)
Date: Fri, 01 Jul 2011 21:52:05 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1309557125.49.0.527056129767.issue10898@psf.upfronthosting.co.za>


Alan Hourihane <alanh at fairlite.co.uk> added the comment:

No, that patch still doesn't work.

----------
resolution: fixed -> accepted

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

From report at bugs.python.org  Sat Jul  2 00:02:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Jul 2011 22:02:11 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1309557731.79.0.585060353374.issue10898@psf.upfronthosting.co.za>


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

Hum, can you propose something?

----------

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

From report at bugs.python.org  Sat Jul  2 00:14:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 22:14:13 +0000
Subject: [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1309558453.12.0.0472996467386.issue12472@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

That's because struct timeval is not defined by <sys/time.h> on IRIX, or it doesn't get included in Modules/signalmodule.c.

Can you try to compile the following code with the same compiler/options?

"""
#include <sys/time.h>

int main(int argc, char *argv[])
{
    struct timeval tv;

    return 0;
}
"""

By the way, is IRIX an officially supported platform?

----------
nosy: +haypo, neologix

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

From report at bugs.python.org  Sat Jul  2 00:23:22 2011
From: report at bugs.python.org (kais58)
Date: Fri, 01 Jul 2011 22:23:22 +0000
Subject: [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1309559002.26.0.667566832447.issue12472@psf.upfronthosting.co.za>


kais58 <kais58 at sucs.org> added the comment:

./test.c: In function 'main':
./test.c:5: warning: unused variable 'tv'

is what it gives back.

----------

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

From report at bugs.python.org  Sat Jul  2 00:25:34 2011
From: report at bugs.python.org (Alan Hourihane)
Date: Fri, 01 Jul 2011 22:25:34 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1309559134.4.0.481989967739.issue10898@psf.upfronthosting.co.za>


Alan Hourihane <alanh at fairlite.co.uk> added the comment:

I've had to split the three #undef's up to just before they're used.

----------

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

From report at bugs.python.org  Sat Jul  2 00:30:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 22:30:40 +0000
Subject: [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1309559440.34.0.36258208329.issue12472@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Ok, what happens if you change, in Modules/signalmodule.c

20 #ifdef HAVE_SYS_TIME_H     
21 #include <sys/time.h>
22 #endif

to

21 #include <sys/time.h>

and rebuild Python?

----------

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

From report at bugs.python.org  Sat Jul  2 00:36:31 2011
From: report at bugs.python.org (kais58)
Date: Fri, 01 Jul 2011 22:36:31 +0000
Subject: [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1309559791.67.0.886308092963.issue12472@psf.upfronthosting.co.za>


kais58 <kais58 at sucs.org> added the comment:

In file included from ./Modules/signalmodule.c:23:
/usr/include/sys/time.h:186: error: static declaration of 'select' follows non-static declaration
/usr/include/unistd.h:479: error: previous declaration of 'select' was here
make: *** [Modules/signalmodule.o] Error 1

----------

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

From report at bugs.python.org  Sat Jul  2 01:10:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 23:10:22 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309561822.78.0.0213585090926.issue12469@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

What happens if you create the thread after having registered the SIGBUS handler?

----------

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

From report at bugs.python.org  Sat Jul  2 01:17:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 01 Jul 2011 23:17:49 +0000
Subject: [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1309562269.73.0.752143737575.issue12472@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

You can't include both <unistd.h> and <sys/time.h> on IRIX...
Nice one!

A couple suggestions (in this order):
1) try putting "#include <sys/time.h>" before "#include "Python.h""

2) try this:
20 #undef select
21 #include <sys/time.h>

3) fix the header yourself (remove the static storage class from select in <sys/time.h>)

4) complain loudly to your vendor...

----------

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

From report at bugs.python.org  Sat Jul  2 01:49:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Jul 2011 23:49:53 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309564193.13.0.575056952446.issue12469@psf.upfronthosting.co.za>


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

On FreeBSD 6, os.kill(os.getpid(), signum) calls immediatly the signal handler before the creation of the first thread (which was the case by default before my commit 024827a9db64), whereas the signal handler is called "later" (when exactly?) after the creation of the first thread (default after my commit).

The traceback is sometimes "truncated" because tstate->frame is NULL. I suppose that the signal handler is called after the execution of the last instruction, after PyEval_EvalFrameEx() has set tstate->frame to f->f_back (which is NULL for the last frame).

----------

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

From report at bugs.python.org  Sat Jul  2 02:15:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Jul 2011 00:15:59 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309565759.32.0.476623553404.issue12469@psf.upfronthosting.co.za>


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

> What happens if you create the thread after having registered
> the SIGBUS handler?

I reverted my commit and created the thread after the call to faulthandler.register(). It changes nothing, the signal handler is still called "later" sometimes.

> On FreeBSD 6, os.kill(os.getpid(), signum) calls immediatly
> the signal handler before the creation of the first thread (...),
> whereas the signal handler is called "later" (when exactly?) after
> the creation of the first thread (default after my commit).

It looks like a kernel/libc bug. At least, it doesn't conform to POSIX.1-2001. Extract of the Linux manual page of the kill function (syscall):

"POSIX.1-2001  requires that if a process sends a signal to itself, and the sending thread does not have the signal blocked, and no other thread has it unblocked or is waiting for it in sigwait(3), at least  one  unblocked  signal must be delivered to the sending thread before the kill() returns."

I see two options:

 - revert my commit and fix #12392 (test_signal) differently
 - skip test_register, test_register_file, test_register_threads and test_stack_overflow can on freebsd6

I prefer to revert my commit because it introduced an unexpected behaviour on signal handling. It calls the signal handler later when the process sends a signal to itself, even if the application don't use threads.

The new fix for #12392 is to ensure that at least one thread was created. We can for example use the following code at the beginning of test_signal:

if sys.platform in ('freebsd5', 'freebsd6'):
  #?On FreeBSD6, pthread_kill() doesn't work on the main thread
  # before?the creation of the first thread
  import threading
  t = threading.Thread(target=lambda: None)
  t.start()
  t.join()

Then test_signal.test_pthread_kill_main_thread() should be skipped or patched for freebsd6.

----------

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

From report at bugs.python.org  Sat Jul  2 02:26:24 2011
From: report at bugs.python.org (Peter Williams)
Date: Sat, 02 Jul 2011 00:26:24 +0000
Subject: [issue12457] type() returns incorrect type for nested classes
In-Reply-To: <1309497940.68.0.603392922196.issue12457@psf.upfronthosting.co.za>
Message-ID: <1309566384.96.0.748131316958.issue12457@psf.upfronthosting.co.za>


Peter Williams <pwil3058 at bigpond.net.au> added the comment:

The class I was pickling was a top level class but a field inside that class had an instance of a nested class set as its value.  The error message produced indicated that the reason for failure was the inability of pickle to find the class definition and (I think) that was caused by the problem with type()'s returned value.

Perhaps fixing the problem with type() would allow the restriction on pickling nested classes to be removed?  Was that restriction a deliberate design decision (illogical) or the result of not being able to get it to work?

Re whether the behaviour of type() is a problem:  I believe it is as, in addition to the inconsistencies between type() and isinstance() that I described in my original report, there is the confusion that arises if two separate classes have nested classes with the same name (see mini program confusion.py as an example).  This seems to compromise the whole purpose of namespaces and is inconsistent with the way modules are treated in determining the name reported by type().

----------
type: behavior -> crash
Added file: http://bugs.python.org/file22544/confusion.py

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

From report at bugs.python.org  Sat Jul  2 05:17:17 2011
From: report at bugs.python.org (Tom Rini)
Date: Sat, 02 Jul 2011 03:17:17 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1309576637.61.0.772006554772.issue7846@psf.upfronthosting.co.za>


Tom Rini <tom.rini at gmail.com> added the comment:

So yes, we have some code that was doing, roughly:
if any(fnmatchcase(key, pat) for pat in pattern):
   refs.add(key)
on 200-300 elements, a lot.  That said, many of them were not globs so we've worked around this to only use fnmatchcase on globs and just key in set otherwise.  Things are now usable on python 2.6.6+ (so Ubuntu 10.10) and noise otherwise.

----------

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

From report at bugs.python.org  Sat Jul  2 09:21:10 2011
From: report at bugs.python.org (HaiYun Yan)
Date: Sat, 02 Jul 2011 07:21:10 +0000
Subject: [issue12473] factory func of collections.defaultdict should receive
	the "missing key" as args when called.
In-Reply-To: <1309591270.02.0.438510682407.issue12473@psf.upfronthosting.co.za>
Message-ID: <1309591270.02.0.438510682407.issue12473@psf.upfronthosting.co.za>


New submission from HaiYun Yan <lyricconch at gmail.com>:

for example:

def calc(params):
    """ i am factoring numbers. """
    # an expensive CPU cost function but 
    # passin params and return result are both lightweight

cachedcalc = collections.defaultdict(calc)
result = cachedcalc[0xFFFFFFFFFFFFFFFFFFF0AC0FFF1]

----------
components: Library (Lib)
messages: 139624
nosy: lyricconch
priority: normal
severity: normal
status: open
title: factory func of collections.defaultdict should receive the "missing key" as args when called.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jul  2 09:45:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Jul 2011 07:45:07 +0000
Subject: [issue12401] unset PYTHON* environment variables when running tests
In-Reply-To: <1308952676.91.0.708236346954.issue12401@psf.upfronthosting.co.za>
Message-ID: <1309592707.03.0.981751003169.issue12401@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti, michael.foord

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

From report at bugs.python.org  Sat Jul  2 10:31:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 02 Jul 2011 08:31:12 +0000
Subject: [issue12473] factory func of collections.defaultdict should receive
	the "missing key" as args when called.
In-Reply-To: <1309591270.02.0.438510682407.issue12473@psf.upfronthosting.co.za>
Message-ID: <1309595472.0.0.288482265636.issue12473@psf.upfronthosting.co.za>


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

-1. Besides compatibility issues, defaultdict is a dict: it contains data, and is not meant to consume CPU when accessing items. Its "default" function should return initial values, like 0 or an empty list.

I think what you want is "memoization"; a memoized function still looks like a function! there are many implementations for python, one of these is here: http://wiki.python.org/moin/PythonDecoratorLibrary#Memoize

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

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

From report at bugs.python.org  Sat Jul  2 10:31:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 08:31:23 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309565759.32.0.476623553404.issue12469@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2jHVU2r527q0njnEgKXGBc4FNS=vet9mF19KNaTddEsg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>> On FreeBSD 6, os.kill(os.getpid(), signum) calls immediatly
>> the signal handler before the creation of the first thread (...),
>> whereas the signal handler is called "later" (when exactly?) after
>> the creation of the first thread (default after my commit).
>
> It looks like a kernel/libc bug. At least, it doesn't conform to POSIX.1-2001. Extract of the Linux manual page of the kill function (syscall):
>

Yes, that's definitely a kernel/libc bug, like  #12392.

> I see two options:
>
> ?- revert my commit and fix #12392 (test_signal) differently
> ?- skip test_register, test_register_file, test_register_threads and test_stack_overflow can on freebsd6
>
> I prefer to revert my commit because it introduced an unexpected behaviour on signal handling. It calls the signal handler later when the process sends a signal to itself, even if the application don't use threads.
>

I'm also in favor of reverting this commit.

> The new fix for #12392 is to ensure that at least one thread was created. We can for example use the following code at the beginning of test_signal:
>
> if sys.platform in ('freebsd5', 'freebsd6'):
> ?#?On FreeBSD6, pthread_kill() doesn't work on the main thread
> ?# before?the creation of the first thread
> ?import threading
> ?t = threading.Thread(target=lambda: None)
> ?t.start()
> ?t.join()
>
> Then test_signal.test_pthread_kill_main_thread() should be skipped or patched for freebsd6.
>

Yes.

By the way, this also explains the test.test_signal.WakeupSignalTests
failures we had on FreeBSD 6.4.
Here's what I wrote in see http://bugs.python.org/issue8407#msg137382 :

"""
"""
======================================================================
FAIL: test_signum (test.test_signal.WakeupSignalTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py",
line 272, in test_signum
    self.check_signum(signal.SIGUSR1, signal.SIGALRM)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_signal.py",
line 238, in check_signum
    self.assertEqual(raised, signals)
AssertionError: Tuples differ: (14, 30) != (30, 14)

First differing element 0:
14
30

- (14, 30)
+ (30, 14)
"""

This means that the signals are not delivered in order.
Normally, pending signals are checked upon return to user-space, so
trip_signal should be called when the kill syscall returns, so signal
numbers should be written in order to the wakeup FD (and here it looks
like the lowest-numbered signal is delivered first).
You could try adding a short sleep before the second kill (or just
pass unordered=True to check_signum, but in that case we don't check
the correct ordering).
"""

Since signals are not delivered synchronously when the kill() syscall
returns, they are delivered later, and the order is not preserved.

The patch above (creating a dummy thread at the beginning of
test_signal) should fix this, so you might be able to revert
http://hg.python.org/cpython/rev/29e08a98281d .

----------

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

From report at bugs.python.org  Sat Jul  2 11:09:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 09:09:47 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <BANLkTim1fEsWRQB2fxqPh0KeuE+8LZStcw@mail.gmail.com>
Message-ID: <CAH_1eM3vjOSaG_Nf3u0RX=tYzJwK=1WPuW=SMTNfZAdHhFSdug@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file22545/heap_gc_deadlock_lockless.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12352>
_______________________________________
-------------- next part --------------
diff -r fcf242243d46 Lib/multiprocessing/heap.py
--- a/Lib/multiprocessing/heap.py	Sun Jun 26 15:29:27 2011 +0200
+++ b/Lib/multiprocessing/heap.py	Sat Jul 02 10:59:15 2011 +0200
@@ -101,6 +101,8 @@
         self._stop_to_block = {}
         self._allocated_blocks = set()
         self._arenas = []
+        # list of pending blocks to free - see free() comment below
+        self._pending_free_blocks = []
 
     @staticmethod
     def _roundup(n, alignment):
@@ -175,15 +177,39 @@
 
         return start, stop
 
+    def _free_pending_blocks(self):
+        # Free all the blocks in the pending list - called with the lock held.
+        while True:
+            try:
+                block = self._pending_free_blocks.pop()
+            except IndexError:
+                break
+            self._allocated_blocks.remove(block)
+            self._free(block)
+
     def free(self, block):
         # free a block returned by malloc()
+        # Since free() can be called asynchronously by the GC, it could happen
+        # that it's called while self._lock is held: in that case,
+        # self._lock.acquire() would deadlock (issue #12352). To avoid that, a
+        # trylock is used instead, and if the lock can't be acquired
+        # immediately, the block is added to a list of blocks to be freed
+        # synchronously sometimes later from malloc() or free(), by calling
+        # _free_pending_blocks() (appending and retrieving from a list is not
+        # strictly thread-safe but under cPython it's atomic thanks to the GIL).
         assert os.getpid() == self._lastpid
-        self._lock.acquire()
-        try:
-            self._allocated_blocks.remove(block)
-            self._free(block)
-        finally:
-            self._lock.release()
+        if not self._lock.acquire(0):
+            # can't acquire the lock right now, add the block to the list of
+            # pending blocks to free
+            self._pending_free_blocks.append(block)
+        else:
+            # we hold the lock
+            try:
+                self._free_pending_blocks()
+                self._allocated_blocks.remove(block)
+                self._free(block)
+            finally:
+                self._lock.release()
 
     def malloc(self, size):
         # return a block of right size (possibly rounded up)
@@ -191,6 +217,7 @@
         if os.getpid() != self._lastpid:
             self.__init__()                     # reinitialize after fork
         self._lock.acquire()
+        self._free_pending_blocks()
         try:
             size = self._roundup(max(size,1), self._alignment)
             (arena, start, stop) = self._malloc(size)
diff -r fcf242243d46 Lib/test/test_multiprocessing.py
--- a/Lib/test/test_multiprocessing.py	Sun Jun 26 15:29:27 2011 +0200
+++ b/Lib/test/test_multiprocessing.py	Sat Jul 02 10:59:15 2011 +0200
@@ -1738,6 +1738,29 @@
             self.assertTrue((arena != narena and nstart == 0) or
                             (stop == nstart))
 
+    def test_free_from_gc(self):
+        # Check that freeing of blocks by the garbage collector doesn't deadlock
+        # (issue #12352).
+        # Make sure the GC is enabled, and set lower collection thresholds to
+        # make collections more frequent (and increase the probability of
+        # deadlock).
+        if gc.isenabled():
+            thresholds = gc.get_threshold()
+            self.addCleanup(gc.set_threshold, *thresholds)
+        else:
+            gc.enable()
+            self.addCleanup(gc.disable)
+        gc.set_threshold(10)
+
+        # perform numerous block allocations, with cyclic references to make
+        # sure objects are collected asynchronously by the gc
+        for i in range(5000):
+            a = multiprocessing.heap.BufferWrapper(1)
+            b = multiprocessing.heap.BufferWrapper(1)
+            # circular references
+            a.buddy = b
+            b.buddy = a
+
 #
 #
 #

From report at bugs.python.org  Sat Jul  2 11:10:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Jul 2011 09:10:34 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309597834.06.0.941289964546.issue12291@psf.upfronthosting.co.za>


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

Can we get this committed for 3.2.1 then?

----------

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

From report at bugs.python.org  Sat Jul  2 11:13:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 09:13:05 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309597985.08.0.427954086762.issue12352@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22546/heap_gc_deadlock_lockless.diff

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

From report at bugs.python.org  Sat Jul  2 11:13:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 09:13:17 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309597997.39.0.245970136666.issue12352@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22477/heap_gc_deadlock.diff

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

From report at bugs.python.org  Sat Jul  2 11:13:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 09:13:28 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309598008.98.0.532755558212.issue12352@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22490/heap_gc_deadlock_lockless.diff

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

From report at bugs.python.org  Sat Jul  2 11:13:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 09:13:45 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309598025.63.0.080667711235.issue12352@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22545/heap_gc_deadlock_lockless.diff

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

From report at bugs.python.org  Sat Jul  2 12:10:53 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 02 Jul 2011 10:10:53 +0000
Subject: [issue12465] gc.get_referents can be used to crash Python
In-Reply-To: <1309524235.61.0.692133767187.issue12465@psf.upfronthosting.co.za>
Message-ID: <1309601453.54.0.942514355986.issue12465@psf.upfronthosting.co.za>


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

This looks a lot like the crasher described in Lib/test/crashers/underlying_dict.py

For the record, the similar issue1517663 was closed even though there was a patch, with a comment of the "if it hurts, don't do it" kind.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Sat Jul  2 12:10:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Jul 2011 10:10:59 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309601459.02.0.683571181101.issue12352@psf.upfronthosting.co.za>


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

The last heap_gc_deadlock_lockless.diff	looks good.

Note: please try to use different filenames for different versions of the same patch. For example, add a number (heap_gc_deadlock_lockless-2.diff) to the name.

----------

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

From report at bugs.python.org  Sat Jul  2 12:11:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 10:11:27 +0000
Subject: [issue12468] longjmp causes uninitialized stack frame
In-Reply-To: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>
Message-ID: <1309601487.5.0.721869470611.issue12468@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Digging a little deeper:
- in ./Modules/fpectlmodule.c, the longjmp() is actually not used at all (dead code)
- in Modules/readline.c, the jmp_buf is correctly initialized (well, there's a tiny race condition because SIGINT handler is installed before setjmp() initializes jbuf, but it's not worth fixing)

In this case, I'm 99% sure the culprit is:
import pycurl

That's a know bug in libcurl:
"longjmp causes uninitialized stack frame" in libcurl's alarmfunc running gwibber-daemon
https://bugzilla.redhat.com/show_bug.cgi?id=539809

Suggesting to close as invalid.

----------

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

From report at bugs.python.org  Sat Jul  2 12:16:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 10:16:19 +0000
Subject: [issue12468] longjmp causes uninitialized stack frame
In-Reply-To: <1309541648.47.0.579386081097.issue12468@psf.upfronthosting.co.za>
Message-ID: <1309601779.86.0.164715013463.issue12468@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

And the backtrace leaves no doubt:
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2415de61d7]
/lib/x86_64-linux-gnu/libc.so.6(+0xfe169)[0x7f2415de6169]
/lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33)[0x7f2415de60d3]
/usr/lib/libcurl-gnutls.so.4(+0xbb45)[0x7f241528bb45]

The longjmp is in libcurl.
Closing as invalid.

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

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

From report at bugs.python.org  Sat Jul  2 12:24:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Jul 2011 10:24:38 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309602278.01.0.220404635322.issue12469@psf.upfronthosting.co.za>


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

> I'm also in favor of reverting this commit.

Hum, the problem is that the Python test suite creates a lot of threads. Revert the patch doesn't change anything for the test suite. I mean that all tests relying on signal delivery should (must) be running in a new fresh process, especially if the test expects that the signal is received immediatly (as described in POSIX). If we don't use a subprocess, the tests will fail sometimes if at least one thread was created before.

I will try to write a patch which implement all requirements we listed in this issue. I just fear that it is a little bit overkill just to support an "old" (?) OS. But fixing a test for FreeBSD 6 improves usually the reliability on other OSes, especially when we replaced fork() by subprocess.

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

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

From report at bugs.python.org  Sat Jul  2 12:32:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 02 Jul 2011 10:32:05 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309602725.05.0.331911385286.issue12469@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Revert the patch doesn't change anything for the test suite.

I know, but at least it doesn't change the default - be it broken - behaviour on FreeBSD 6.

> I just fear that it is a little bit overkill just to support an "old" (?) OS.

Yes. I mean, we can't expect Python signal machinery to work when the underlying OS is broken.
I personally think we should just skip all those failing tests on FreeBSD6.

----------

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

From report at bugs.python.org  Sat Jul  2 12:52:12 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 02 Jul 2011 10:52:12 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1309603932.62.0.466967737897.issue10883@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here's an updated patch implementing reference counting for ftpwrapper.
It changes the semantics of ftpwrapper.close() to postpone actually closing
the connection until all files have also been closed (like socket.close()).

----------
Added file: http://bugs.python.org/file22547/issue10883.patch

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

From report at bugs.python.org  Sat Jul  2 13:43:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 02 Jul 2011 11:43:15 +0000
Subject: [issue12474] Invalid read in symtable.c
In-Reply-To: <1309606995.45.0.154486187515.issue12474@psf.upfronthosting.co.za>
Message-ID: <1309606995.45.0.154486187515.issue12474@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

After 151142c0c5b1 Valgrind finds an invalid read in symtable.c, line 907:

  st->st_cur = (PySTEntryObject *)PyList_GET_ITEM(st->st_stack, size - 2);


==14301== Memcheck, a memory error detector
==14301== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==14301== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==14301== Command: ./python
==14301== 
==14301== Invalid read of size 8
==14301==    at 0x4A1B30: symtable_exit_block (symtable.c:907)
==14301==    by 0x49FFA3: PySymtable_Build (symtable.c:276)
==14301==    by 0x473B42: PyAST_CompileEx (compile.c:295)
==14301==    by 0x49E37D: run_mod (pythonrun.c:1790)
==14301==    by 0x49E10E: PyRun_StringFlags (pythonrun.c:1727)
==14301==    by 0x45EBFB: builtin_exec (bltinmodule.c:818)
==14301==    by 0x54E2FF: PyCFunction_Call (methodobject.c:81)
==14301==    by 0x471B4C: call_function (ceval.c:3957)
==14301==    by 0x46D482: PyEval_EvalFrameEx (ceval.c:2663)
==14301==    by 0x470060: PyEval_EvalCodeEx (ceval.c:3393)
==14301==    by 0x47208A: fast_function (ceval.c:4055)
==14301==    by 0x471C9F: call_function (ceval.c:3978)
==14301==  Address 0x691df18 is 8 bytes before a block of size 32 alloc'd
==14301==    at 0x4C27972: realloc (vg_replace_malloc.c:525)
==14301==    by 0x5367FB: list_resize (listobject.c:62)
==14301==    by 0x537F5B: list_ass_slice (listobject.c:643)
==14301==    by 0x5381BA: PyList_SetSlice (listobject.c:677)
==14301==    by 0x4A1B61: symtable_exit_block (symtable.c:909)
==14301==    by 0x4A2997: symtable_visit_stmt (symtable.c:1128)
==14301==    by 0x49FED2: PySymtable_Build (symtable.c:256)
==14301==    by 0x473B42: PyAST_CompileEx (compile.c:295)
==14301==    by 0x49E37D: run_mod (pythonrun.c:1790)
==14301==    by 0x49E10E: PyRun_StringFlags (pythonrun.c:1727)
==14301==    by 0x45EBFB: builtin_exec (bltinmodule.c:818)
==14301==    by 0x54E2FF: PyCFunction_Call (methodobject.c:81)

----------
components: Interpreter Core
messages: 139636
nosy: benjamin.peterson, skrah
priority: normal
severity: normal
status: open
title: Invalid read in symtable.c
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  2 13:46:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 02 Jul 2011 11:46:14 +0000
Subject: [issue12465] gc.get_referents can be used to crash Python
In-Reply-To: <1309524235.61.0.692133767187.issue12465@psf.upfronthosting.co.za>
Message-ID: <1309607174.21.0.139693120945.issue12465@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/issue12465>
_______________________________________

From report at bugs.python.org  Sat Jul  2 13:48:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 02 Jul 2011 11:48:35 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309607315.94.0.689730584472.issue12459@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/issue12459>
_______________________________________

From report at bugs.python.org  Sat Jul  2 13:50:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Jul 2011 11:50:18 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309607418.2.0.152896808487.issue12352@psf.upfronthosting.co.za>


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

+        if gc.isenabled():
+            thresholds = gc.get_threshold()
+            self.addCleanup(gc.set_threshold, *thresholds)
+        else:
+            gc.enable()
+            self.addCleanup(gc.disable)

It seems you won't restore the thresholds if the GC wasn't enabled at first.

----------

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

From report at bugs.python.org  Sat Jul  2 13:52:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Jul 2011 11:52:29 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1309559134.4.0.481989967739.issue10898@psf.upfronthosting.co.za>
Message-ID: <1309607506.3650.12.camel@localhost.localdomain>


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

> I've had to split the three #undef's up to just before they're used.

I would really prefer to move up the offending #include rather than
sprinkle those #undef's all over the place.

----------

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

From report at bugs.python.org  Sat Jul  2 13:57:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 11:57:47 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <E1QcypQ-00036v-PQ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 96a0788583c6 by Charles-Fran?ois Natali in branch '2.7':
Issue #12352: Fix a deadlock in multiprocessing.Heap when a block is freed by
http://hg.python.org/cpython/rev/96a0788583c6

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Jul  2 14:09:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 12:09:49 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <E1Qcz1A-0004UN-Da@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 874143242d79 by Charles-Fran?ois Natali in branch '2.7':
Issue #12352: In test_free_from_gc(), restore the GC thresholds even if the GC
http://hg.python.org/cpython/rev/874143242d79

----------

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

From report at bugs.python.org  Sat Jul  2 14:36:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 12:36:25 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <E1QczQu-00062h-1Q@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0d4ca1e77205 by Charles-Fran?ois Natali in branch '3.1':
Issue #12352: Fix a deadlock in multiprocessing.Heap when a block is freed by
http://hg.python.org/cpython/rev/0d4ca1e77205

----------

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

From report at bugs.python.org  Sat Jul  2 14:40:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 12:40:22 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <E1QczUi-0006Fn-Sg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 37606505b227 by Charles-Fran?ois Natali in branch '3.2':
Merge issue #12352: Fix a deadlock in multiprocessing.Heap when a block is
http://hg.python.org/cpython/rev/37606505b227

----------

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

From report at bugs.python.org  Sat Jul  2 14:43:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 12:43:42 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <E1QczXw-0006Ny-U5@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fd8dc3746992 by Charles-Fran?ois Natali in branch 'default':
Merge issue #12352: Fix a deadlock in multiprocessing.Heap when a block is
http://hg.python.org/cpython/rev/fd8dc3746992

----------

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

From report at bugs.python.org  Sat Jul  2 14:49:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 12:49:01 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1309610941.25.0.0533545929005.issue12409@psf.upfronthosting.co.za>


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

I don?t understand Fred?s replies.

> The scope of this document is much larger than Python's documentation,
> but extends to all projects written in Python that use Sphinx as their
> documentation tool.
Really?  docs.python.org/documenting is much smaller that sphinx.pocoo.org, and only seems to cover documenting Python, not any Python project.

> With that, it makes sense to keep it as part of the documentation for
> users of Python.
I don?t follow.  You?re saying that since the document also covers other projects than Python, it makes sense to include it in the Python docs?

IMO, the criterion for the devguide is to have version-independent documents in one place instead of needlessly including them with CPython and having to sync across versions.  For the Documenting Python docs, if they contain version-specific instructions, or if they contain instructions needed in a CPython tarball, then they?re in the right place, otherwise they could move to the devguide.

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

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

From report at bugs.python.org  Sat Jul  2 15:21:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:21:33 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309612893.67.0.593253735806.issue12442@psf.upfronthosting.co.za>


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

Looks like my message on Rietveld was not received or not read:

http://bugs.python.org/review/12442/diff/2951/7664#newcode776

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

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

From report at bugs.python.org  Sat Jul  2 15:36:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:36:29 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1309613789.59.0.728266067229.issue9968@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Sat Jul  2 15:41:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:41:14 +0000
Subject: [issue6234] cgi.FieldStorage is broken when given POST data
In-Reply-To: <1244412456.94.0.493968112391.issue6234@psf.upfronthosting.co.za>
Message-ID: <1309614074.34.0.120097164163.issue6234@psf.upfronthosting.co.za>


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

Closing as duplicate.  The other report has more discussion.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> WSGI, cgi.FieldStorage incompatibility

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

From report at bugs.python.org  Sat Jul  2 15:49:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:49:32 +0000
Subject: [issue11066] cgi.py proposals : sys.stdout encoding + rewriting of
	parsing functions
In-Reply-To: <1296335741.52.0.506773731017.issue11066@psf.upfronthosting.co.za>
Message-ID: <1309614572.9.0.559754479579.issue11066@psf.upfronthosting.co.za>


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

See also #1610654 and #6234.

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

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

From report at bugs.python.org  Sat Jul  2 15:52:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:52:29 +0000
Subject: [issue1573931] WSGI, cgi.FieldStorage incompatibility
Message-ID: <1309614749.53.0.0664734579344.issue1573931@psf.upfronthosting.co.za>


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

Now that web-sig has reached agreement on PEP 3333, can an expert update the status of this bug?

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

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

From report at bugs.python.org  Sat Jul  2 15:53:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:53:28 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309614808.3.0.829562317886.issue12411@psf.upfronthosting.co.za>


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

This looks like a conversion bug indeed; network I/O should use bytes.  Strange that no-one caught this, but if there was no test and no users, then bugs can slip.

See also #11066, #8077, #4953, #6234 (also adding some people from those bugs? nosy fields).

----------
nosy: +MHordecki, efosmark, eric.araujo, flox, milesck, quentel
versions: +Python 3.2

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

From report at bugs.python.org  Sat Jul  2 15:56:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:56:25 +0000
Subject: [issue12412] non defined representation for pwd.struct_passwd
In-Reply-To: <1309017290.05.0.556727126165.issue12412@psf.upfronthosting.co.za>
Message-ID: <1309614985.44.0.162217801285.issue12412@psf.upfronthosting.co.za>


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

The docs indeed don?t say more that ?Password database entries are reported as a tuple-like object, whose attributes correspond to the members of the passwd structure?; no mention is made of named tuple or struct sequence.

I think there is no bug for CPython; you may want to suggest friendlier reprs for structseqs to PyPy.

----------
nosy: +benjamin.peterson, eric.araujo
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jul  2 15:57:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 13:57:42 +0000
Subject: [issue12414] getsizeof() on code objects is wrong
In-Reply-To: <1309060401.87.0.459388249467.issue12414@psf.upfronthosting.co.za>
Message-ID: <1309615062.07.0.20118912015.issue12414@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


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

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

From report at bugs.python.org  Sat Jul  2 15:57:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 02 Jul 2011 13:57:43 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309615063.69.0.0851733748262.issue12442@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I removed the percent usage from the returned namedtuple hence that comment is no longer necessary.

----------

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

From report at bugs.python.org  Sat Jul  2 16:01:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 14:01:16 +0000
Subject: [issue12415] Missing: How to checkout the Doc sources
In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>
Message-ID: <1309615276.89.0.576142434922.issue12415@psf.upfronthosting.co.za>


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

How about adding this near the top of documenting/building:

  The sources for the Python documentation are included in the
  Python repository, alongside code and tests.  Follow the
  instructions in the `Developpers' Guide`_ to get a copy of this
  repository.

  _Developpers's Guide: http://docs.python.org/devguide

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul  2 16:02:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 14:02:37 +0000
Subject: [issue12418] python should inherit the library search path from the
	compiler for stdlib extensions
In-Reply-To: <1309176139.38.0.221668771682.issue12418@psf.upfronthosting.co.za>
Message-ID: <1309615357.34.0.00183399314172.issue12418@psf.upfronthosting.co.za>


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

Do you know if all compilers supported by CPython have a similar option?

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

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

From report at bugs.python.org  Sat Jul  2 16:18:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 14:18:06 +0000
Subject: [issue12474] Invalid read in symtable.c
In-Reply-To: <1309606995.45.0.154486187515.issue12474@psf.upfronthosting.co.za>
Message-ID: <E1Qd11J-0003Sb-Ag@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6b3872a11299 by Benjamin Peterson in branch 'default':
fix possibily uninitialized memory usage (closes #12474)
http://hg.python.org/cpython/rev/6b3872a11299

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jul  2 16:30:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 14:30:42 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309617042.8.0.128050930715.issue12442@psf.upfronthosting.co.za>


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

Ah, excellent!  Thanks for the new function.  About using assertGreater and friends in tests, as Ezio and I suggested, I have done the change in my working copy and will commit it later.

----------

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

From report at bugs.python.org  Sat Jul  2 16:32:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 14:32:32 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1309617152.02.0.0488609813426.issue9561@psf.upfronthosting.co.za>


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

>> Okay.  I guess you?ll use codecs.open in 2.7
> Oh, Python 2.7... DistributionMetadata of distutils encodes most
> values to byte strings (get_xxx() methods calls self._encode_field).
I forgot that.  No change is needed in 2.7.

> I checked, there is not bootstrap issue.
I was talking about bootstrapping if a change to use codecs was made.

----------

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

From report at bugs.python.org  Sat Jul  2 16:34:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 14:34:02 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1309617242.57.0.331913384045.issue12449@psf.upfronthosting.co.za>


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

Distutils is frozen.  New features go into distutils2.

----------

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

From report at bugs.python.org  Sat Jul  2 16:39:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 02 Jul 2011 14:39:18 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <1309617558.72.0.858374155442.issue11363@psf.upfronthosting.co.za>


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

Yes, the typo is also on default; I did not mention it, as the merge would have shown it :)

I did not report the bug I found; if you could test all examples for 3.x-compat and open a report, it would be great.

----------

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

From report at bugs.python.org  Sat Jul  2 16:47:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 14:47:41 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <E1Qd1Tw-0005Ga-7n@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 479973c6aa03 by ?ric Araujo in branch 'default':
Clean up NEWS entry and tests for shutil.disk_usage (#12442)
http://hg.python.org/cpython/rev/479973c6aa03

----------

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

From report at bugs.python.org  Sat Jul  2 16:53:53 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 02 Jul 2011 14:53:53 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309618433.61.0.108557472759.issue12442@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Thanks for the further fixes.

----------

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

From report at bugs.python.org  Sat Jul  2 17:43:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 15:43:19 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <E1Qd2Ll-00009M-O6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset edba722f3b02 by Vinay Sajip in branch '3.2':
Closes #12291: Fixed bug which was found when doing  multiple loads from one stream.
http://hg.python.org/cpython/rev/edba722f3b02

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jul  2 18:16:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 16:16:12 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <E1Qd2ra-0002F0-O7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 42dd11028e94 by Vinay Sajip in branch 'default':
Closes #12291 for 3.3 - merged fix from 3.2.
http://hg.python.org/cpython/rev/42dd11028e94

----------

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

From report at bugs.python.org  Sat Jul  2 19:52:24 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Jul 2011 17:52:24 +0000
Subject: [issue12291] file written using marshal in 3.2 can be read by 2.7,
	but not 3.2 or 3.3
In-Reply-To: <1307610610.3.0.00172759046416.issue12291@psf.upfronthosting.co.za>
Message-ID: <1309629144.28.0.987945520437.issue12291@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/issue12291>
_______________________________________

From report at bugs.python.org  Sat Jul  2 21:21:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jul 2011 19:21:15 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <E1Qd5kg-00054D-Fu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 51c1f2cedb96 by Antoine Pitrou in branch 'default':
Issue #12456: fix a possible hang on shutdown of a concurrent.futures.ProcessPoolExecutor.
http://hg.python.org/cpython/rev/51c1f2cedb96

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Jul  2 21:21:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Jul 2011 19:21:35 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309634495.93.0.751476544432.issue12456@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul  2 22:01:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 02 Jul 2011 20:01:21 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1309636881.8.0.0931640969293.issue1054041@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


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

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

From report at bugs.python.org  Sat Jul  2 22:38:13 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 02 Jul 2011 20:38:13 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309639093.15.0.855323505553.issue12043@psf.upfronthosting.co.za>


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

It turns out it was just move() with a slightly outdated description; so I take the occasion to fix some minor stuff in the doc.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22548/issue12043-default.patch

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

From report at bugs.python.org  Sat Jul  2 22:38:19 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 02 Jul 2011 20:38:19 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309639099.02.0.220694622353.issue12043@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file22549/issue12043-27.patch

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

From report at bugs.python.org  Sun Jul  3 02:38:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Jul 2011 00:38:10 +0000
Subject: [issue12442] shutil.disk_usage()
In-Reply-To: <1309366539.23.0.219360747776.issue12442@psf.upfronthosting.co.za>
Message-ID: <1309653490.56.0.578963368017.issue12442@psf.upfronthosting.co.za>


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


----------
stage: commit review -> committed/rejected

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

From report at bugs.python.org  Sun Jul  3 03:14:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jul 2011 01:14:32 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <E1QdBGY-0007nP-Ux@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0f5ea42fb46c by R David Murray in branch '3.2':
#12147: make send_message correctly handle Sender and Resent- headers.
http://hg.python.org/cpython/rev/0f5ea42fb46c

New changeset b8cec4f3faaa by R David Murray in branch 'default':
merge #12147: make send_message correctly handle Sender and Resent- headers.
http://hg.python.org/cpython/rev/b8cec4f3faaa

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Jul  3 03:16:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Jul 2011 01:16:24 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1309655784.65.0.962725027038.issue12147@psf.upfronthosting.co.za>


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

I tweaked the patch a bit (mostly style/cosmetic) and added some additional tests.  Thanks, Nicolas!

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

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

From report at bugs.python.org  Sun Jul  3 03:26:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Jul 2011 01:26:27 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309656387.63.0.285627738122.issue12411@psf.upfronthosting.co.za>


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

Indeed, Victor's comments on his patch say that he changed code that was in the posted patch to say 'line.startswith(b'--')', and the original patch did use b'--', but the code he checked in is missing the 'b'.  He also asked for more tests.

Victor, any chance you can review this patch, since you were the last one to work on the code in question?

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

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

From report at bugs.python.org  Sun Jul  3 07:32:11 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 03 Jul 2011 05:32:11 +0000
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <20110626211827.GC2710@mathmagic>
Message-ID: <CAPkN8x++tAJJb=DciZmoenokBu8HXiyTMr9nB6W4JiOJFXk0+w@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Jun 27, 2011 at 12:18 AM, Senthil Kumaran
<report at bugs.python.org> wrote:
> As you said, the future version can be updated, but we
> cannot go back with updating the documentation of the already released
> versions.

Why?
--
anatoly t.

----------

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

From report at bugs.python.org  Sun Jul  3 09:07:44 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 03 Jul 2011 07:07:44 +0000
Subject: [issue12475] Generator bug allows you to chain arbitrary tracebacks
	to the next raised exception
In-Reply-To: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>
Message-ID: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

It's probably best shown by example:

http://ideone.com/4YkqV

Have fun! This one looks hard.

Some notes: Exchanging g2() for iter([1]) makes this go away. Wrapping g2 inside a non-generator iterator does not make this go away. 

Removing the call to next(it) after it = g2() makes the problem go away, as does replacing those two lines with next(g2()).

The file used in that ideone paste is attached for your convenience.

---

Debugging is impractical for me with this bug in existence. It never stopped printing the traceback before I killed the process. (And let's forget about debug prints!)

----------
components: Interpreter Core
files: exception_chaining.py
messages: 139670
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: Generator bug allows you to chain arbitrary tracebacks to the next raised exception
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22550/exception_chaining.py

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

From report at bugs.python.org  Sun Jul  3 09:17:04 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 03 Jul 2011 07:17:04 +0000
Subject: [issue12475] Generator bug allows you to chain arbitrary tracebacks
	to the next raised exception
In-Reply-To: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>
Message-ID: <1309677424.61.0.693715183077.issue12475@psf.upfronthosting.co.za>


Changes by Devin Jeanpierre <jeanpierreda at gmail.com>:


Removed file: http://bugs.python.org/file22550/exception_chaining.py

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

From report at bugs.python.org  Sun Jul  3 09:17:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Jul 2011 07:17:58 +0000
Subject: [issue12346] Python source code build fails with old mercurial
In-Reply-To: <1308212064.93.0.160132143903.issue12346@psf.upfronthosting.co.za>
Message-ID: <1309677478.99.0.15166077077.issue12346@psf.upfronthosting.co.za>


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

435eec7b41f0 transplanted to 3.2 in 4e0c1128cda2.

----------
versions:  -Python 3.2

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

From report at bugs.python.org  Sun Jul  3 09:22:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jul 2011 07:22:49 +0000
Subject: [issue12225] current tip doesn't build without mercurial installed
In-Reply-To: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>
Message-ID: <E1QdH0y-0002Qk-JU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4e0c1128cda2 by Ralf Schmitt in branch '3.2':
disable ASDLGEN if hg won't work, or if python is not installed.
http://hg.python.org/cpython/rev/4e0c1128cda2

----------

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

From report at bugs.python.org  Sun Jul  3 09:27:18 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Jul 2011 07:27:18 +0000
Subject: [issue12475] Generator bug allows you to chain arbitrary tracebacks
	to the next raised exception
In-Reply-To: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>
Message-ID: <1309678038.95.0.46816331967.issue12475@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/issue12475>
_______________________________________

From report at bugs.python.org  Sun Jul  3 09:51:02 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Jul 2011 07:51:02 +0000
Subject: [issue12465] gc.get_referents can be used to crash Python
In-Reply-To: <1309524235.61.0.692133767187.issue12465@psf.upfronthosting.co.za>
Message-ID: <1309679462.67.0.923899148757.issue12465@psf.upfronthosting.co.za>


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

Yep. It's no surprise that you can crash Python by abusing the gc module, or the ctypes module, or ...

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Jul  3 10:02:37 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 03 Jul 2011 08:02:37 +0000
Subject: [issue12476] ctypes: need example how to pass raw data from Python
In-Reply-To: <1309680157.38.0.0819979072917.issue12476@psf.upfronthosting.co.za>
Message-ID: <1309680157.38.0.0819979072917.issue12476@psf.upfronthosting.co.za>


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

ctypes documentation lacks an example, how to pass a raw data block from Python to a C function. For example, how to pass this chunk:

data = open('somefile', 'rb').read()

to this function:

int checkBuffer(LPSTR lpData, DWORD dwBufferLength);

?

----------
assignee: docs at python
components: Documentation, ctypes
messages: 139675
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: ctypes: need example how to pass raw data from Python
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jul  3 10:52:26 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 03 Jul 2011 08:52:26 +0000
Subject: [issue12476] ctypes: need example how to pass raw data from Python
In-Reply-To: <1309680157.38.0.0819979072917.issue12476@psf.upfronthosting.co.za>
Message-ID: <1309683146.37.0.285512065426.issue12476@psf.upfronthosting.co.za>


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

Can you suggest a patch?

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Sun Jul  3 11:35:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jul 2011 09:35:49 +0000
Subject: [issue12406] msi.py needs updating for Python 3.3
In-Reply-To: <1308995950.75.0.288905614048.issue12406@psf.upfronthosting.co.za>
Message-ID: <E1QdJ5f-0001Iy-Ia@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3ce11ddc9ec3 by Vinay Sajip in branch 'default':
Issue #12406: Added upates for packaging's .exe files, command_template, and sysconfig.cfg.
http://hg.python.org/cpython/rev/3ce11ddc9ec3

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Jul  3 11:40:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 03 Jul 2011 09:40:38 +0000
Subject: [issue12352] multiprocessing.Value() hangs
In-Reply-To: <1308316788.45.0.312348703073.issue12352@psf.upfronthosting.co.za>
Message-ID: <1309686038.24.0.107117998289.issue12352@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test passes on all the buildbots, closing.
greg, thanks for reporting this!

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

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

From report at bugs.python.org  Sun Jul  3 11:41:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 03 Jul 2011 09:41:58 +0000
Subject: [issue7123] Multiprocess Process does not always exit when run from a
	thread.
In-Reply-To: <1255522492.52.0.0352108851469.issue7123@psf.upfronthosting.co.za>
Message-ID: <1309686118.78.0.0700595257963.issue7123@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I am pretty sure this is another instance of issue 6721.

Indeed.
Closing as duplicate.

----------
status: open -> closed
superseder:  -> Locks in python standard library should be sanitized on fork

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

From report at bugs.python.org  Sun Jul  3 11:45:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 03 Jul 2011 09:45:38 +0000
Subject: [issue8035] urllib.request.urlretrieve hangs waiting for connection
	close after a redirect
In-Reply-To: <1267470113.93.0.44679631442.issue8035@psf.upfronthosting.co.za>
Message-ID: <1309686338.82.0.766339927215.issue8035@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
keywords: +needs review
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jul  3 12:07:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jul 2011 10:07:27 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309687647.3.0.0496925699206.issue12456@psf.upfronthosting.co.za>


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

Looks like I broke the OS X buildbots:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/609/steps/test/logs/stdio

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

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

From report at bugs.python.org  Sun Jul  3 12:46:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jul 2011 10:46:18 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309689978.42.0.206182099844.issue12456@psf.upfronthosting.co.za>


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

Ok, qsize() can raise NotImplementedError on OS X, which explains quite a bit:

Exception in thread Thread-2:
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/custom.parc-snowleopard-1/build/Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/Users/buildbot/buildarea/custom.parc-snowleopard-1/build/Lib/threading.py", line 690, in run
    self._target(*self._args, **self._kwargs)
  File "/Users/buildbot/buildarea/custom.parc-snowleopard-1/build/Lib/concurrent/futures/process.py", line 271, in _queue_management_worker
    if not pending_work_items and call_queue.qsize() == 0:
  File "/Users/buildbot/buildarea/custom.parc-snowleopard-1/build/Lib/multiprocessing/queues.py", line 139, in qsize
    return self._maxsize - self._sem._semlock._get_value()
NotImplementedError

----------

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

From report at bugs.python.org  Sun Jul  3 13:03:38 2011
From: report at bugs.python.org (Atsushi Odagiri)
Date: Sun, 03 Jul 2011 11:03:38 +0000
Subject: [issue12477] input() does'nt strip CR
In-Reply-To: <1309691018.52.0.674006633314.issue12477@psf.upfronthosting.co.za>
Message-ID: <1309691018.52.0.674006633314.issue12477@psf.upfronthosting.co.za>


New submission from Atsushi Odagiri <aodagx at gmail.com>:

Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input()
a
'a\r'


Python 3.1.3 (r313:86834, Nov 27 2010, 17:20:37) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> input()
a
'a'

----------
messages: 139682
nosy: Atsushi.Odagiri
priority: normal
severity: normal
status: open
title: input() does'nt strip CR
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Jul  3 13:05:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Jul 2011 11:05:51 +0000
Subject: [issue12477] input() does'nt strip CR
In-Reply-To: <1309691018.52.0.674006633314.issue12477@psf.upfronthosting.co.za>
Message-ID: <1309691151.19.0.0512702888211.issue12477@psf.upfronthosting.co.za>


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

This is a duplicate of #11272, which will be fixed in 3.2.1.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> input() has trailing carriage return on windows

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

From report at bugs.python.org  Sun Jul  3 13:17:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jul 2011 11:17:56 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <E1QdKgR-0006f7-V0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ce52310f61a0 by Antoine Pitrou in branch 'default':
Followup to 51c1f2cedb96 (and issue #12456):
http://hg.python.org/cpython/rev/ce52310f61a0

----------

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

From report at bugs.python.org  Sun Jul  3 14:14:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 03 Jul 2011 12:14:28 +0000
Subject: [issue12478] Possible error in HTTPErrorProcessor documentation
In-Reply-To: <1309695268.0.0.0456155108685.issue12478@psf.upfronthosting.co.za>
Message-ID: <1309695268.0.0.0456155108685.issue12478@psf.upfronthosting.co.za>


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

Hello, I think HTTPErrorProcessor documentation at [1] contains a cut&paste error (from UnknownHandler) for the only method available

[1] http://docs.python.org/py3k/library/urllib.request.html#httperrorprocessor-objects

because:

./python -c "import urllib.request as ur; print ('unknown_open' in dir(ur.HTTPErrorProcessor))"
False

If you can confirm that http_response() should be used instead, I'll provide a patch to fix it.

----------
assignee: docs at python
components: Documentation
messages: 139685
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Possible error in HTTPErrorProcessor documentation
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  3 14:24:44 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 03 Jul 2011 12:24:44 +0000
Subject: [issue12476] ctypes: need example how to pass raw data from Python
In-Reply-To: <1309680157.38.0.0819979072917.issue12476@psf.upfronthosting.co.za>
Message-ID: <1309695884.1.0.382537823756.issue12476@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

ISTM that this code works ok.


data = open('data.raw', 'rb').read()
ret = checkBuffer(data, len(data))


You need to make sure that checkBuffer doesn't try to modify memory though. For mutable memory blocks use create_string_buffer().

----------

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

From report at bugs.python.org  Sun Jul  3 14:46:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jul 2011 12:46:29 +0000
Subject: [issue12456] Hangs in concurrent.futures
In-Reply-To: <1309497923.23.0.957560996312.issue12456@psf.upfronthosting.co.za>
Message-ID: <1309697189.03.0.0478558575441.issue12456@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/issue12456>
_______________________________________

From report at bugs.python.org  Sun Jul  3 14:53:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 03 Jul 2011 12:53:39 +0000
Subject: [issue12479] Add HTTPErrorProcessor class definition
In-Reply-To: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>
Message-ID: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>


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

As reported in http://mail.python.org/pipermail/docs/2011-June/004879.html urllibs/urllib.request misses the definition of HTTPErrorProcessor class; the attached patches add it to the documentation.

----------
assignee: docs at python
components: Documentation
files: HTTPErrorProcessor_class-default.patch
keywords: patch
messages: 139687
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Add HTTPErrorProcessor class definition
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22552/HTTPErrorProcessor_class-default.patch

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

From report at bugs.python.org  Sun Jul  3 14:53:45 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 03 Jul 2011 12:53:45 +0000
Subject: [issue12479] Add HTTPErrorProcessor class definition
In-Reply-To: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>
Message-ID: <1309697625.64.0.226530088841.issue12479@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file22553/HTTPErrorProcessor_class-py27.patch

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

From report at bugs.python.org  Sun Jul  3 16:26:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Jul 2011 14:26:38 +0000
Subject: [issue12475] Generator bug allows you to chain arbitrary tracebacks
	to the next raised exception
In-Reply-To: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>
Message-ID: <1309703198.93.0.349968206515.issue12475@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul  3 17:16:12 2011
From: report at bugs.python.org (Or)
Date: Sun, 03 Jul 2011 15:16:12 +0000
Subject: [issue12480] urllib2 doesn't use proxy (fieddler2),
	configed the proxy with ProxyHandler
In-Reply-To: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>
Message-ID: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>


New submission from Or <yellowslider at gmail.com>:

I have fieddler2 listening on 0.0.0.0:8888.

this code is suppose to use the proxy on my localhost.

try:
    data = '' 
    proxy = urllib2.ProxyHandler({'http': '127.0.0.1:8888'})  //also tried {'http': 'http://127.0.0.1:8888/'}
    opener = urllib2.build_opener(proxy)
    urllib2.install_opener(opener)
    req = urllib2.Request('http://www.google.com')
    response = urllib2.urlopen(req)
    the_page = response.read()
        print the_page
except Exception, detail:
    print "Err ", detail


	

I have fieddler2 listening on 0.0.0.0:8888.

try:
    proxy = urllib2.ProxyHandler({'http': '127.0.0.1:8888'})  //also tried {'http': 'http://127.0.0.1:8888/'}
    opener = urllib2.build_opener(proxy)
    urllib2.install_opener(opener)
    req = urllib2.Request('http://www.google.com')
    response = urllib2.urlopen(req)
    the_page = response.read()
        print the_page
except Exception, detail:
    print "Err ", detail

I don't see the GET or any request to google in fieddler (but I can see other requests) is there a way to debug it? is seems like python bypasses fieddler or ignores the proxy.

the code is working, but it's not using the proxy to fetch google, it bypasses the proxy.

I also configured win7 to work with fieddler -

C:\Windows\system32>netsh winhttp set proxy 127.0.0.1:8888

Current WinHTTP proxy settings:

    Proxy Server(s) :  127.0.0.1:8888
    Bypass List     :  (none)

In order to check if the code is using the porxy I've changed fieddler to require proxy authentication and I had to use a user\pass on my browser when browsing, run the python code again and it worked, so it defiantly doesn't use the proxy.

----------
components: Extension Modules, Library (Lib), Windows
messages: 139688
nosy: Or.Wilder
priority: normal
severity: normal
status: open
title: urllib2 doesn't use proxy (fieddler2), configed the proxy with ProxyHandler
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul  3 17:18:06 2011
From: report at bugs.python.org (Or)
Date: Sun, 03 Jul 2011 15:18:06 +0000
Subject: [issue12480] urllib2 doesn't use proxy (fieddler2),
	configed the proxy with ProxyHandler
In-Reply-To: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>
Message-ID: <1309706286.17.0.874187293389.issue12480@psf.upfronthosting.co.za>


Or <yellowslider at gmail.com> added the comment:

I have fieddler2 listening on 0.0.0.0:8888.

this code is suppose to use the proxy on my localhost.

try:
    proxy = urllib2.ProxyHandler({'http': '127.0.0.1:8888'})  //also tried {'http': 'http://127.0.0.1:8888/'}
    opener = urllib2.build_opener(proxy)
    urllib2.install_opener(opener)
    req = urllib2.Request('http://www.google.com')
    response = urllib2.urlopen(req)
    the_page = response.read()
        print the_page
except Exception, detail:
    print "Err ", detail

I don't see the GET or any request to google in fieddler (but I can see other requests) is there a way to debug it? is seems like python bypasses fieddler or ignores the proxy.

the code is working, but it's not using the proxy to fetch google, it bypasses the proxy.

I also configured win7 to work with fieddler -

C:\Windows\system32>netsh winhttp set proxy 127.0.0.1:8888

Current WinHTTP proxy settings:

    Proxy Server(s) :  127.0.0.1:8888
    Bypass List     :  (none)

In order to check if the code is using the porxy I've changed fieddler to require proxy authentication and I had to use a user\pass on my browser when browsing, run the python code again and it worked, so it defiantly doesn't use the proxy.

----------

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

From report at bugs.python.org  Sun Jul  3 18:11:01 2011
From: report at bugs.python.org (Philip Olson)
Date: Sun, 03 Jul 2011 16:11:01 +0000
Subject: [issue12415] Missing: How to checkout the Doc sources
In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>
Message-ID: <1309709461.29.0.525708752165.issue12415@psf.upfronthosting.co.za>


Philip Olson <philip at roshambo.org> added the comment:

Thank you, that patch solves this bug report.

However, now I'm not sure which branches we should or must contribute documentation to. Python versions "2.7, 3.2, and 3.3" are now associated to this bug report, so are these the active documentation branches? How is this handled?

----------

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

From report at bugs.python.org  Sun Jul  3 18:33:10 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Jul 2011 16:33:10 +0000
Subject: [issue12481] test_faulthandler: popups on Windows/Debug/x64
In-Reply-To: <1309710790.64.0.229703159898.issue12481@psf.upfronthosting.co.za>
Message-ID: <1309710790.64.0.229703159898.issue12481@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I'm getting the dreaded "python_d.exe has stopped working" popups
in test_faulthandler on Windows 7 + VisualStudioPro + "Debug|x64".

----------
components: Tests
messages: 139691
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: test_faulthandler: popups on Windows/Debug/x64
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul  3 19:18:07 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 03 Jul 2011 17:18:07 +0000
Subject: [issue12412] non defined representation for pwd.struct_passwd
In-Reply-To: <1309017290.05.0.556727126165.issue12412@psf.upfronthosting.co.za>
Message-ID: <1309713487.39.0.755027373552.issue12412@psf.upfronthosting.co.za>


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

pypy did not use a structseq in this case. Fixed in (pypy's repo) dded6e510044

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Sun Jul  3 19:25:10 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Jul 2011 17:25:10 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1309190312.72.0.0963947939619.issue10020@psf.upfronthosting.co.za>
Message-ID: <20110703172505.GA3937@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed the indentation issues. We could not use automatic reST
footnotes because two links refer to same footnote, so left it as
such.

----------

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

From report at bugs.python.org  Sun Jul  3 19:47:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Jul 2011 17:47:42 +0000
Subject: [issue12412] non defined representation for pwd.struct_passwd
In-Reply-To: <1309017290.05.0.556727126165.issue12412@psf.upfronthosting.co.za>
Message-ID: <1309715262.18.0.0954113532662.issue12412@psf.upfronthosting.co.za>


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

But pypy passed the attribute access tests in the test suite?

----------

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

From report at bugs.python.org  Sun Jul  3 20:44:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jul 2011 18:44:34 +0000
Subject: [issue12475] Generator bug allows you to chain arbitrary tracebacks
	to the next raised exception
In-Reply-To: <1309676864.45.0.345140180481.issue12475@psf.upfronthosting.co.za>
Message-ID: <E1QdRei-0008Hu-Kp@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cc7ae81cfe91 by Benjamin Peterson in branch '3.2':
restore a generator's caller's exception state both on yield and (last) return
http://hg.python.org/cpython/rev/cc7ae81cfe91

New changeset 33dca840938d by Benjamin Peterson in branch 'default':
merge 3.2 (#12475)
http://hg.python.org/cpython/rev/33dca840938d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jul  3 20:58:52 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Sun, 03 Jul 2011 18:58:52 +0000
Subject: [issue12480] urllib2 doesn't use proxy (fieddler2),
	configed the proxy with ProxyHandler
In-Reply-To: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>
Message-ID: <1309719532.0.0.354294106225.issue12480@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

I setup a proxy and it seems to be working properly. This is on win7 x64 professional using Python 2.7.1

I didn't using any sniffing software but if I broke the proxy the code broke. When I enabled the proxy it started working again. My proxy log also shows record of the access.

----------
nosy: +thomas.holmes

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

From report at bugs.python.org  Sun Jul  3 21:23:50 2011
From: report at bugs.python.org (Dmitriy Gorbachev)
Date: Sun, 03 Jul 2011 19:23:50 +0000
Subject: [issue12482] input() not working correctly on Mac OS X
In-Reply-To: <1309721030.16.0.565553010826.issue12482@psf.upfronthosting.co.za>
Message-ID: <1309721030.16.0.565553010826.issue12482@psf.upfronthosting.co.za>


New submission from Dmitriy Gorbachev <dgorbachev at yahoo.com>:

I am learning Python by running exercises from "Programming Python", Mark Lutz on both Windows and Mac. While exercises run flawlessly on Windows, sometimes they do not run on Mac.
In particular, in Chapter 1, Step 2: Storing Records Persistently there is a script called make_db_file.py. The following function loadDbase (called by dump_db_file_test.py-see attached) is not working at all on Mac, but working fine of Windows. 
The code breaks on the line: key = input(). 
The Traceback message is as follows:
Traceback (most recent call last):
  File "dump_db_file_test.py", line 2, in <module>
    db = loadDbase()
  File "/Users/DMITRY/PythonScripts/make_db_file_test.py", line 22, in loadDbase
    key = input()
  File "<string>", line 1, in <module>
NameError: name 'bob' is not defined

Where 'bob' is the first line of the text file "people-file" that make_db_file_test.py refers.
All related files attached in BugReport.zip

Best regards

Dmitry

----------
assignee: ronaldoussoren
components: Macintosh
files: BugReport.zip
messages: 139697
nosy: dgorbachev, ronaldoussoren
priority: normal
severity: normal
status: open
title: input() not working correctly on Mac OS X
versions: Python 2.7
Added file: http://bugs.python.org/file22554/BugReport.zip

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

From report at bugs.python.org  Sun Jul  3 21:45:58 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 03 Jul 2011 19:45:58 +0000
Subject: [issue12439] BaseHTTPServer's send_reponse adds extra "\r\n" when
	using HTTPMessage in input
In-Reply-To: <1309340125.43.0.831188381846.issue12439@psf.upfronthosting.co.za>
Message-ID: <1309722358.59.0.944617906049.issue12439@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

It seems to me that you're indeed misusing it.

The correct way would be something like this (assuming response is a HTTPResponse object from httplib):

self.send_response(response.status)
for name, value in response.getheaders():
    self.send_header(name, value)
self.end_headers()

This is because send_response's second argument is the HTTP's "reason" field, i.e. invoking:

    self.send_response(123, 'FOOBAR')

results in 

    HTTP/1.1 123 FOOBAR\r\n

to be sent, followed by "Server" and "Date" headers. The second argument is not meant to be used for sending headers.

(When the second argument is omitted, a standard reason for the given status code is used.)

----------
nosy: +petri.lehtinen
resolution:  -> invalid

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

From report at bugs.python.org  Sun Jul  3 22:05:25 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 03 Jul 2011 20:05:25 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <1309723525.55.0.979803558025.issue12448@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Behaves incorrectly for me, too. Attached a patch with the suggested fix.

----------
keywords: +needs review, patch
nosy: +petri.lehtinen
Added file: http://bugs.python.org/file22555/smtplib_main_prompt.patch

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

From report at bugs.python.org  Sun Jul  3 22:05:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Jul 2011 20:05:50 +0000
Subject: [issue1067702] urllib fails with multiple ftp transfers
In-Reply-To: <1309164343.54.0.647232997116.issue1067702@psf.upfronthosting.co.za>
Message-ID: <20110703200545.GB3937@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hello Stefen, 

Yes, I was able to reproduce the issue without the patch and at the
same time, noticed that the problem was not observed in other branches
(py3k), then saw the differences where the possible socket close
delays can happen and fixed it. As it was multiple threads closely
being closed it was most probably due to delay in closing socket
connection that lead the problem in the first place.

If it is required, then manually this can be verified by setting up an
artificial delay in the network layer and trying multiple ftp
transfers. (No, I did not do that to verify. :))

----------

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

From report at bugs.python.org  Sun Jul  3 22:07:20 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 03 Jul 2011 20:07:20 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
	lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1309723640.09.0.629317432328.issue12458@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Sun Jul  3 22:08:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 03 Jul 2011 20:08:02 +0000
Subject: [issue12482] input() not working correctly on Mac OS X
In-Reply-To: <1309721030.16.0.565553010826.issue12482@psf.upfronthosting.co.za>
Message-ID: <1309723682.92.0.53850862859.issue12482@psf.upfronthosting.co.za>


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

You are certainly using Python 2 with code designed for Python 3...
Can you check?

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Sun Jul  3 22:08:32 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 03 Jul 2011 20:08:32 +0000
Subject: [issue12461] it's not clear how the shutil.copystat() should work on
	symlinks
In-Reply-To: <1309513358.23.0.446931887968.issue12461@psf.upfronthosting.co.za>
Message-ID: <1309723712.76.0.910003259187.issue12461@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Sun Jul  3 22:08:52 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 03 Jul 2011 20:08:52 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1309723732.67.0.180836038234.issue12463@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Sun Jul  3 22:09:28 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 03 Jul 2011 20:09:28 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1309723768.9.0.583124344267.issue12464@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Sun Jul  3 22:10:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Jul 2011 20:10:04 +0000
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <CAPkN8x++tAJJb=DciZmoenokBu8HXiyTMr9nB6W4JiOJFXk0+w@mail.gmail.com>
Message-ID: <20110703200958.GC3937@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

What's new docs are usually for what is coming up new in the upcoming
releases. It is not updated once the release is done. Bug fixes and
related docs are updated in documentation.

----------

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

From report at bugs.python.org  Sun Jul  3 22:18:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Jul 2011 20:18:35 +0000
Subject: [issue12482] input() not working correctly on Mac OS X
In-Reply-To: <1309721030.16.0.565553010826.issue12482@psf.upfronthosting.co.za>
Message-ID: <1309724315.49.0.770156194486.issue12482@psf.upfronthosting.co.za>


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

The test case you've provide is working as expected but the code doesn't make a lot of sense as provided.  The function loadDbase sets sys.stdin to a disk file but never sets it back again.  If you run this in an interactive interpreter on any Unix-like system and call that function, it will leave sys.stdin still connected to the disk file which will give unexpected results.  I don't have a copy of the book so I don't know how the author recommends to run things but it won't work as it stands (also, the function loadDbase is incomplete compared with the book's example files).  You can remove the immediate problem by adding the following line just before the "return db" at the end of loadDbase:
    sys.stdin = sys.__stdin__
That will restore the original value of sys.stdin.

You may want to ask questions like this on either the tutor mailing list or comp.lang.python.

http://www.python.org/community/lists/ 

http://docs.python.org/library/sys.html#sys.__stdin__

----------
assignee: ronaldoussoren -> 
components:  -Macintosh
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jul  3 22:38:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Jul 2011 20:38:44 +0000
Subject: [issue12481] test_faulthandler: popups on Windows/Debug/x64
In-Reply-To: <1309710790.64.0.229703159898.issue12481@psf.upfronthosting.co.za>
Message-ID: <1309725524.12.0.132407369801.issue12481@psf.upfronthosting.co.za>


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

Duplicate of issue #11732.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sun Jul  3 22:39:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Jul 2011 20:39:00 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1309725540.67.0.732194922064.issue11732@psf.upfronthosting.co.za>


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

Issue #12481 has been marked as duplicate: "I'm getting the dreaded "python_d.exe has stopped working" popups in test_faulthandler on Windows 7 + VisualStudioPro + "Debug|x64"."

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

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

From report at bugs.python.org  Sun Jul  3 22:41:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Jul 2011 20:41:19 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1309725679.07.0.658085861791.issue11732@psf.upfronthosting.co.za>


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

"Most (all?) Windows machines have error reporting enabled unless you mess with the registry manually"

It is disabled on all Windows buildbots. test_capi does also test a crash (I don't know/remember which test exactly).

----------

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

From report at bugs.python.org  Sun Jul  3 22:42:59 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Jul 2011 20:42:59 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1309725779.0.0.520818373971.issue11732@psf.upfronthosting.co.za>


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

For test_capi the patch in #9116 works. For test_faulthandler it
doesn't, unfortunately.

----------

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

From report at bugs.python.org  Sun Jul  3 23:04:48 2011
From: report at bugs.python.org (Thijs Triemstra)
Date: Sun, 03 Jul 2011 21:04:48 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309727088.98.0.862283353176.issue12398@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/issue12398>
_______________________________________

From report at bugs.python.org  Sun Jul  3 23:05:34 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Jul 2011 21:05:34 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1309727134.74.0.665018948422.issue11732@psf.upfronthosting.co.za>


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

"Instead of skipping the test, I prefer to disable temporary the popup by setting the right registry key (and then restore the previous value or delete the key)."

Do you mean that the user should change/restore the key or that the
Python tests should do that? I think we shouldn't mess with system
settings, even if we restore them.


BTW, it would be a great help to print a warning (also in test_capi)
that the popups are expected.

----------

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

From report at bugs.python.org  Sun Jul  3 23:22:13 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 03 Jul 2011 21:22:13 +0000
Subject: [issue12391] packaging install fails to clean up temp files
In-Reply-To: <1308815016.03.0.685993126745.issue12391@psf.upfronthosting.co.za>
Message-ID: <1309728133.17.0.617636706369.issue12391@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
hgrepos: +35

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

From report at bugs.python.org  Sun Jul  3 23:22:53 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 03 Jul 2011 21:22:53 +0000
Subject: [issue12391] packaging install fails to clean up temp files
In-Reply-To: <1308815016.03.0.685993126745.issue12391@psf.upfronthosting.co.za>
Message-ID: <1309728173.82.0.368462042887.issue12391@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22556/7ee51c480fec.diff

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

From report at bugs.python.org  Sun Jul  3 23:35:29 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 03 Jul 2011 21:35:29 +0000
Subject: [issue5619] Pass MS CRT debug flags into subprocesses
In-Reply-To: <1238472783.0.0.132667741337.issue5619@psf.upfronthosting.co.za>
Message-ID: <1309728929.34.0.171075575677.issue5619@psf.upfronthosting.co.za>


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

Related issues with patches: #9116 and #11732

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

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

From report at bugs.python.org  Mon Jul  4 00:00:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Jul 2011 22:00:18 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1309730418.22.0.122224120182.issue11732@psf.upfronthosting.co.za>


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

> Do you mean that the user should change/restore the key
> or that the Python tests should do that?

Python can change temporary the registry value for the duration of the test.

----------

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

From report at bugs.python.org  Mon Jul  4 00:46:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Jul 2011 22:46:57 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <1309733217.86.0.206357511138.issue12467@psf.upfronthosting.co.za>


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

The assertion occurs in setup_context() of Python/_warnings.c, called by fileio_dealloc_warn(). The problem is that globals()['__file__'] is None.

Attached patch should fix this issue.

----------
keywords: +patch
nosy: +pitrou
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22557/warn_unicode.patch

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

From report at bugs.python.org  Mon Jul  4 00:50:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Jul 2011 22:50:40 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <1309733440.41.0.578747546207.issue12467@psf.upfronthosting.co.za>


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

Test script to reproduce the assertion.

----------
Added file: http://bugs.python.org/file22558/test_warn_assert.py

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

From report at bugs.python.org  Mon Jul  4 00:51:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jul 2011 22:51:29 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <1309733489.92.0.283803915588.issue12467@psf.upfronthosting.co.za>


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

Nice diagnosis!

----------
stage:  -> commit review

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

From report at bugs.python.org  Mon Jul  4 00:51:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Jul 2011 22:51:56 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <1309733516.93.0.0974563867477.issue12467@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul  4 01:10:26 2011
From: report at bugs.python.org (Alan Hourihane)
Date: Sun, 03 Jul 2011 23:10:26 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1309734626.16.0.290593448242.issue10898@psf.upfronthosting.co.za>


Alan Hourihane <alanh at fairlite.co.uk> added the comment:

Well, I'd probably prefer something akin to my first patch then.

There's no need to #undef things at all if we just prefix the usage with PYTHON_

----------

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

From report at bugs.python.org  Mon Jul  4 01:15:50 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 03 Jul 2011 23:15:50 +0000
Subject: [issue11909] Doctest sees directives in strings when it should only
	see them in comments
In-Reply-To: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>
Message-ID: <1309734950.96.0.965733716775.issue11909@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

Updated patch to newest revision, and to use _tokenize function and includes a test case to verify that it ignores the encoding directive during the tokenization (and every other) step.

I'll file a tokenize bug separately.

----------
Added file: http://bugs.python.org/file22559/comments.diff

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

From report at bugs.python.org  Mon Jul  4 01:29:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jul 2011 23:29:14 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QdW6C-00004w-MN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 81424281ee59 by Victor Stinner in branch '3.2':
Issue #12451: xml.dom.pulldom: parse() now opens files in binary mode instead
http://hg.python.org/cpython/rev/81424281ee59

New changeset c039c6b58907 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: xml.dom.pulldom: parse() now opens files in binary
http://hg.python.org/cpython/rev/c039c6b58907

----------

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

From report at bugs.python.org  Mon Jul  4 01:48:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jul 2011 23:48:00 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QdWOM-00011Z-Vv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cd1759711357 by Victor Stinner in branch '3.2':
Issue #12451: runpy: run_path() now opens the Python script in binary mode,
http://hg.python.org/cpython/rev/cd1759711357

New changeset e240af1f0ae1 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: runpy: run_path() now opens the Python script in
http://hg.python.org/cpython/rev/e240af1f0ae1

----------

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

From report at bugs.python.org  Mon Jul  4 02:15:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 00:15:01 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1QdWoS-0002MD-00@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a1b4f1716b73 by Victor Stinner in branch '3.2':
Issue #12451: pydoc: importfile() now opens the Python script in binary mode,
http://hg.python.org/cpython/rev/a1b4f1716b73

New changeset 5ca136dccbf7 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: pydoc: importfile() now opens the Python script in
http://hg.python.org/cpython/rev/5ca136dccbf7

----------

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

From senthil at uthcode.com  Mon Jul  4 02:19:07 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 3 Jul 2011 17:19:07 -0700
Subject: [issue12436] Provide reference to detailed installation
	instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
References: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
	<1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <20110704001907.GA15716@mathmagic>

I am not sure that is comprehensive enough. It is just organized into
OS specific sections and gives little details further on.
So, -1 to this, but +1 to the general idea of having detailed install
and get started documentation.

From report at bugs.python.org  Mon Jul  4 02:19:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Jul 2011 00:19:12 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <20110704001907.GA15716@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I am not sure that is comprehensive enough. It is just organized into
OS specific sections and gives little details further on.
So, -1 to this, but +1 to the general idea of having detailed install
and get started documentation.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Mon Jul  4 02:21:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 00:21:58 +0000
Subject: [issue12432] remove a bunch of unused imports in Lib
In-Reply-To: <1309271895.63.0.491805316904.issue12432@psf.upfronthosting.co.za>
Message-ID: <E1QdWvE-0002lF-VA@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6886e0bf29bc by Senthil Kumaran in branch '3.2':
Fix closes issue12432 - remove the unused sys from glob.py
http://hg.python.org/cpython/rev/6886e0bf29bc

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

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

From report at bugs.python.org  Mon Jul  4 02:40:33 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 04 Jul 2011 00:40:33 +0000
Subject: [issue11909] Doctest sees directives in strings when it should only
	see them in comments
In-Reply-To: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>
Message-ID: <1309740033.7.0.344610783938.issue11909@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

Erp I forgot to run this against the rest of the tests. Disregard, I'll fix it up a bit later.

----------

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

From report at bugs.python.org  Mon Jul  4 02:40:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 00:40:57 +0000
Subject: [issue12438] IDLE problem displaying warning message
In-Reply-To: <1309309591.85.0.564668230133.issue12438@psf.upfronthosting.co.za>
Message-ID: <E1QdXDb-0003lR-UC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c9f69b28c4d1 by Senthil Kumaran in branch '2.7':
Fix closes issue12438  - idlelib.PyShell's showformatwarning method was passing an incorrect arg.
http://hg.python.org/cpython/rev/c9f69b28c4d1

New changeset e9c406a53972 by Senthil Kumaran in branch '3.2':
Fix closes issue12438  - idlelib.PyShell's showformatwarning method was passing an incorrect arg.
http://hg.python.org/cpython/rev/e9c406a53972

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From senthil at uthcode.com  Mon Jul  4 02:42:46 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 3 Jul 2011 17:42:46 -0700
Subject: [issue12438] IDLE problem displaying warning message
In-Reply-To: <1309353045.53.0.675433897422.issue12438@psf.upfronthosting.co.za>
References: <1309309591.85.0.564668230133.issue12438@psf.upfronthosting.co.za>
	<1309353045.53.0.675433897422.issue12438@psf.upfronthosting.co.za>
Message-ID: <20110704004246.GB15716@mathmagic>

Have fixed this. Even looking at the code, your suggestion was
correct. But even before the fix, I was not able to reproduce the bug
in Ubuntu and perhaps it was getting masked. May I ask, how did you
invoke idle that this bug surfaced and what was the platform?

From report at bugs.python.org  Mon Jul  4 02:42:51 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Jul 2011 00:42:51 +0000
Subject: [issue12438] IDLE problem displaying warning message
In-Reply-To: <1309353045.53.0.675433897422.issue12438@psf.upfronthosting.co.za>
Message-ID: <20110704004246.GB15716@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Have fixed this. Even looking at the code, your suggestion was
correct. But even before the fix, I was not able to reproduce the bug
in Ubuntu and perhaps it was getting masked. May I ask, how did you
invoke idle that this bug surfaced and what was the platform?

----------
nosy: +orsenthil

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

From report at bugs.python.org  Mon Jul  4 02:56:40 2011
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 04 Jul 2011 00:56:40 +0000
Subject: [issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
In-Reply-To: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>
Message-ID: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>


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

According to the docs here:

  http://docs.python.org/c-api/gcsupport.html

Any object that uses PyObject_GC_Track in its constructor must call PyObject_GC_UnTrack in its deallocator.  The CThunkObject in _ctypes does the former but not the later.  Attached patch adds a call to PyObject_GC_UnTrack.

This doesn't fix any particular bug I was seeing, I just happened to be going through the _ctypes sources (you know, for fun...) and noticed this discrepancy.

----------
components: ctypes
files: ctypes_gcuntrack.patch
keywords: patch
messages: 139724
nosy: rfk
priority: normal
severity: normal
status: open
title: CThunkObject_dealloc should call PyObject_GC_UnTrack?
versions: Python 3.3
Added file: http://bugs.python.org/file22560/ctypes_gcuntrack.patch

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

From report at bugs.python.org  Mon Jul  4 02:57:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 00:57:07 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <E1QdXTG-0004WO-0z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ac18e70cbe7e by Victor Stinner in branch '3.2':
Issue #12467: warnings: fix a race condition if a warning is emitted at
http://hg.python.org/cpython/rev/ac18e70cbe7e

New changeset 5133fee2433e by Victor Stinner in branch 'default':
(merge 3.2) Issue #12467: warnings: fix a race condition if a warning is
http://hg.python.org/cpython/rev/5133fee2433e

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 03:05:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 01:05:47 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <E1QdXbd-00050A-OD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fc46acf7a645 by Victor Stinner in branch '2.7':
Issue #12467: warnings: fix a race condition if a warning is emitted at
http://hg.python.org/cpython/rev/fc46acf7a645

----------

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

From report at bugs.python.org  Mon Jul  4 03:06:50 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 04 Jul 2011 01:06:50 +0000
Subject: [issue12438] IDLE problem displaying warning message
In-Reply-To: <1309309591.85.0.564668230133.issue12438@psf.upfronthosting.co.za>
Message-ID: <1309741610.17.0.542836680353.issue12438@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

@orsenthil

My system is Ubuntu 11.04 x64. To run idle, i press the Super (windows button) then write idle.

If I open the terminal and type "idle", the problem don't appear but I have to type the password on the terminal rather than on idle GUI.

----------

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

From report at bugs.python.org  Mon Jul  4 03:15:06 2011
From: report at bugs.python.org (Alejandro Santos)
Date: Mon, 04 Jul 2011 01:15:06 +0000
Subject: [issue12484] The Py_InitModule functions no longer exist,
	but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>


New submission from Alejandro Santos <alejolp at alejolp.com>:

While the "Py_InitModule" does not exists on Py3k it is still mentioned on the docs:

http://docs.python.org/py3k/extending/extending.html#keyword-parameters-for-extension-functions
http://docs.python.org/py3k/extending/windows.html#a-cookbook-approach
http://docs.python.org/py3k/faq/extending.html#what-does-systemerror-pyimport-fixupextension-module-yourmodule-not-loaded-mean

----------
assignee: docs at python
components: Documentation
messages: 139728
nosy: alejolp, docs at python
priority: normal
severity: normal
status: open
title: The Py_InitModule functions no longer exist, but remain in the docs
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul  4 03:19:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 01:19:30 +0000
Subject: [issue11066] cgi.py proposals : sys.stdout encoding + rewriting of
	parsing functions
In-Reply-To: <1296335741.52.0.506773731017.issue11066@psf.upfronthosting.co.za>
Message-ID: <1309742370.41.0.826129509526.issue11066@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/issue11066>
_______________________________________

From report at bugs.python.org  Mon Jul  4 03:19:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 01:19:49 +0000
Subject: [issue8077] cgi handling of POSTed files is broken
In-Reply-To: <1267839820.97.0.586792235494.issue8077@psf.upfronthosting.co.za>
Message-ID: <1309742389.81.0.244225440605.issue8077@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/issue8077>
_______________________________________

From report at bugs.python.org  Mon Jul  4 03:22:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 01:22:25 +0000
Subject: [issue12470] Fix cut&paste typo in test_shutil
In-Reply-To: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>
Message-ID: <E1QdXrk-0005rj-93@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 301c008dd58d by Senthil Kumaran in branch '3.2':
Fix closes issue issue12470 - check for utime for the skipUnless condition.
http://hg.python.org/cpython/rev/301c008dd58d

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 03:23:08 2011
From: report at bugs.python.org (Alejandro Santos)
Date: Mon, 04 Jul 2011 01:23:08 +0000
Subject: [issue12484] The Py_InitModule functions no longer exist,
	but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1309742588.43.0.045691980559.issue12484@psf.upfronthosting.co.za>


Alejandro Santos <alejolp at alejolp.com> added the comment:

The call is also present on the older 3.1 and "dev" release of the docs:

http://docs.python.org/release/3.1.3/extending/extending.html#keyword-parameters-for-extension-functions
http://docs.python.org/release/3.1.3/extending/windows.html#a-cookbook-approach
http://docs.python.org/release/3.1.3/faq/extending.html#what-does-systemerror-pyimport-fixupextension-module-yourmodule-not-loaded-mean

http://docs.python.org/dev/extending/extending.html#keyword-parameters-for-extension-functions
http://docs.python.org/dev/extending/windows.html#a-cookbook-approach
http://docs.python.org/dev/faq/extending.html#what-does-systemerror-pyimport-fixupextension-module-yourmodule-not-loaded-mean

----------
versions: +Python 3.1, Python 3.3

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

From report at bugs.python.org  Mon Jul  4 04:13:02 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Mon, 04 Jul 2011 02:13:02 +0000
Subject: [issue12485] Improvement of textwrap module
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>


New submission from Tyler Romeo <tylerromeo at gmail.com>:

Python's textwrap module can be helpful at times, but personally I think there are a couple of things that could be added.

First, when it comes to text wrapping, usually you're not dealing with a monospace font where each letter is the same size. If you're working with the Python Imaging Library for example, there is a function that you pass the text to in order to determine how wide (or tall) a font is. Therefore, it would be useful to have a parameter where the user can pass a function that gives a custom width for a set of text. The default for this parameter, of course, would be len.

Also, this module uses a rough and efficient algorithm for wrapping text, but the results are not always aesthetically pleasing (one word hanging off on a line). Sometimes the user may want something that is wrapped more beautifully, so to say, such as is found in TeX. So there should also be a beautiful option that goes back and redistributes the text so that it is more aesthetically pleasing.

This isn't exactly that important (minor improvements to a module that is probably not used much), but I figured I'd get it out there as I run into the problem all the time when trying to wrap text to be put in images of a set size.

----------
components: Extension Modules
files: textwrap.py-improvement.diff
keywords: patch
messages: 139731
nosy: parent5446
priority: normal
severity: normal
status: open
title: Improvement of textwrap module
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file22561/textwrap.py-improvement.diff

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

From report at bugs.python.org  Mon Jul  4 05:45:35 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 04 Jul 2011 03:45:35 +0000
Subject: [issue11909] Doctest sees directives in strings when it should only
	see them in comments
In-Reply-To: <1303500682.88.0.595944133083.issue11909@psf.upfronthosting.co.za>
Message-ID: <1309751135.4.0.155307697537.issue11909@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

Updated.

----------
Added file: http://bugs.python.org/file22562/comments3.diff

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

From report at bugs.python.org  Mon Jul  4 05:58:17 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 04 Jul 2011 03:58:17 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

tokenize only deals with bytes. Users might want to deal with unicode source (for example, if python source is embedded into a document with an already-known encoding).

The naive approach might be something like:

  def my_readline():
      return my_oldreadline().encode('utf-8')

But this doesn't work for python source that declares its encoding, which might be something other than utf-8. The only safe ways are to either manually add a coding line yourself (there are lots of ways, I picked a dumb one):

  def my_readline_safe(was_read=[]):
      if not was_read:
          was_read.append(True)can 
          return b'# coding: utf-8'
      return my_oldreadline().encode('utf-8')

  tokenstream = tokenize.tokenize(my_readline_safe)

Or to use the same my_readline as before (no added coding line), but instead of passing it to tokenize.tokenize, you could pass it to the undocumented _tokenize function:

    tokenstream = tokenize._tokenize(my_readline, 'utf-8')

Or, ideally, you'd just pass the original readline that produces unicode into a utokenize function:

    tokenstream = tokenize.utokenize(my_oldreadline)

----------
components: Library (Lib)
messages: 139733
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: tokenize module should have a unicode API

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

From report at bugs.python.org  Mon Jul  4 06:05:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 04:05:40 +0000
Subject: [issue12471] wrong TypeError message on '%i' formatting
In-Reply-To: <1309554318.72.0.913120070593.issue12471@psf.upfronthosting.co.za>
Message-ID: <E1QdaPg-0007On-CK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 97707459bb5a by Senthil Kumaran in branch '3.2':
Fix closes issue12471 - wrong TypeError message when '%i' format spec was used.
http://hg.python.org/cpython/rev/97707459bb5a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jul  4 06:38:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 04:38:27 +0000
Subject: [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <E1QdavS-0001ey-CL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8dde71899733 by Ned Deily in branch '2.7':
Issue #10734: Temporarily disable test_ttk test_heading_callback on 2.7 as well.
http://hg.python.org/cpython/rev/8dde71899733

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 06:41:22 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Jul 2011 04:41:22 +0000
Subject: [issue10734] test_ttk failure under Windows
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1309754482.83.0.0237125370095.issue10734@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/issue10734>
_______________________________________

From report at bugs.python.org  Mon Jul  4 06:45:18 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Jul 2011 04:45:18 +0000
Subject: [issue10734] test_ttk test_heading_callback fails with newer Tk 8.5
In-Reply-To: <1292706922.45.0.208964037247.issue10734@psf.upfronthosting.co.za>
Message-ID: <1309754718.61.0.690427490105.issue10734@psf.upfronthosting.co.za>


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

The failure is not unique to Windows.  It fails on OS X with the current ActiveState Tk 8.5.9.  I've temporarily disabled the test on 2.7 as well.

----------
title: test_ttk failure under Windows -> test_ttk test_heading_callback fails with newer Tk 8.5
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Jul  4 07:31:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 05:31:31 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <E1Qdbkn-0004bF-HB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ea02eca122b5 by Ned Deily in branch '2.7':
Issue #8716: Avoid crashes caused by Aqua Tk on OSX when attempting to run
http://hg.python.org/cpython/rev/ea02eca122b5

New changeset 279488f5a171 by Ned Deily in branch '3.2':
Issue #8716: Avoid crashes caused by Aqua Tk on OSX when attempting to run
http://hg.python.org/cpython/rev/279488f5a171

New changeset 5b5a33196916 by Ned Deily in branch 'default':
Issue #8716: Avoid crashes caused by Aqua Tk on OSX when attempting to run
http://hg.python.org/cpython/rev/5b5a33196916

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 07:47:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Jul 2011 05:47:36 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309758456.76.0.413176621215.issue8716@psf.upfronthosting.co.za>


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

Let's try this: when running under OS X, the tk and ttk test runners now perform their initial Tk-available sanity check in a subprocess rather than in the main interpreter process.  If the subprocess fails, the tests are skipped.  There are some differences in behavior across the various OS X releases - 10.4 crashes in more cases than 10.5 and 10.6 - but this should cover them all.  I'll leave this open for a while.  Please log any buildbot regressions here.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Mon Jul  4 08:17:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 06:17:40 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <E1QdcTS-0007HW-L2@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 06cb0d602468 by Ned Deily in branch '2.7':
Issue #8716: Fix errors in the non-OS X path of the 27 backport.
http://hg.python.org/cpython/rev/06cb0d602468

----------
status: pending -> open

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

From report at bugs.python.org  Mon Jul  4 08:36:46 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 04 Jul 2011 06:36:46 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309761406.12.0.0760484695079.issue12043@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/issue12043>
_______________________________________

From report at bugs.python.org  Mon Jul  4 08:37:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Jul 2011 06:37:42 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309761462.32.0.219047847988.issue8716@psf.upfronthosting.co.za>


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


----------
status: open -> pending

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

From report at bugs.python.org  Mon Jul  4 08:38:56 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Jul 2011 06:38:56 +0000
Subject: [issue12470] Fix cut&paste typo in test_shutil
In-Reply-To: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>
Message-ID: <1309761536.99.0.545013805521.issue12470@psf.upfronthosting.co.za>


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

This can be closed?

----------
assignee:  -> orsenthil
nosy: +georg.brandl, orsenthil

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

From report at bugs.python.org  Mon Jul  4 08:49:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Jul 2011 06:49:08 +0000
Subject: [issue12470] Fix cut&paste typo in test_shutil
In-Reply-To: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>
Message-ID: <1309762148.54.0.550627604441.issue12470@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


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

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

From report at bugs.python.org  Mon Jul  4 08:50:21 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Jul 2011 06:50:21 +0000
Subject: [issue12484] The Py_InitModule functions no longer exist,
	but remain in the docs
In-Reply-To: <1309742106.53.0.381388012939.issue12484@psf.upfronthosting.co.za>
Message-ID: <1309762221.4.0.92672235988.issue12484@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

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

From report at bugs.python.org  Mon Jul  4 09:02:38 2011
From: report at bugs.python.org (Nicolas Estibals)
Date: Mon, 04 Jul 2011 07:02:38 +0000
Subject: [issue12147] smtplib.send_message does not implement corectly rfc 2822
In-Reply-To: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>
Message-ID: <1309762958.76.0.550717455514.issue12147@psf.upfronthosting.co.za>


Nicolas Estibals <nicolas.estibals at gmail.com> added the comment:

Thanks for your help and the interesting discussion with this issue.

----------

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

From report at bugs.python.org  Mon Jul  4 09:55:58 2011
From: report at bugs.python.org (Tal Einat)
Date: Mon, 04 Jul 2011 07:55:58 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309766158.51.0.913937293985.issue12411@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

The patch seems broken to me.

In cgi.parse_multipart(), the 'boundary' variable can be a string even though it is concatenated to bytes. Its default value is a string, and a string can be given via the pdict argument. There is no validity check other than valid_boundary(), which allows both string and bytes.

Most of the changes to test_cgi.py are entirely unrelated. The one test added which tests cgi.parse_multipart() should fail since it uses a string (not bytes) boundary, while the correct boundary for the test is commented out.

I short this patch seems half-baked. IMO reject this patch and fix just the bytes/strings issue with cgi.parse_multipart. Or, as mentioned in the comments, use FieldStorage to implement it and be done with it.

----------
nosy: +taleinat

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

From report at bugs.python.org  Mon Jul  4 11:19:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 09:19:09 +0000
Subject: [issue12156] test_multiprocessing.test_notify_all() timeout (1 hour)
	on FreeBSD 7.2
In-Reply-To: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>
Message-ID: <1309771149.79.0.011959589329.issue12156@psf.upfronthosting.co.za>


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

Another recent hang:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1951/steps/test/logs/stdio

[296/356/3] test_multiprocessing
Timeout (1:00:00)!
Thread 0x28402be0:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 237 in wait
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/queue.py", line 185 in get
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 376 in _handle_results
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28402f10:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 237 in wait
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/queue.py", line 185 in get
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 335 in _handle_tasks
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x284039b0:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 326 in _handle_workers
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28402470:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 237 in wait
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/queue.py", line 185 in get
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28402cf0:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 237 in wait
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/queue.py", line 185 in get
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28401bf0:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 237 in wait
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/queue.py", line 185 in get
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28404780:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 237 in wait
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/queue.py", line 185 in get
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28404560:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 409 in _recv
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 430 in _recv_bytes
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 273 in recv
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 376 in _handle_results
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28401e10:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 237 in wait
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/queue.py", line 185 in get
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 335 in _handle_tasks
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Thread 0x28402360:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/pool.py", line 326 in _handle_workers
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 690 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/threading.py", line 710 in _bootstrap

Current thread 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 409 in _recv
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 434 in _recv_bytes
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 239 in recv_bytes
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 1512 in test_connection
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 462 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/case.py", line 514 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1259 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1285 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 2228 in test_main
  File "./Lib/test/regrtest.py", line 1070 in runtest_inner
  File "./Lib/test/regrtest.py", line 861 in runtest
  File "./Lib/test/regrtest.py", line 669 in main
  File "./Lib/test/regrtest.py", line 1648 in <module>
*** Error code 1

----------

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

From report at bugs.python.org  Mon Jul  4 11:21:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 09:21:09 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <1309771269.96.0.303454994293.issue12467@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul  4 11:30:50 2011
From: report at bugs.python.org (Renaud Blanch)
Date: Mon, 04 Jul 2011 09:30:50 +0000
Subject: [issue12471] wrong TypeError message on '%i' formatting
In-Reply-To: <1309554318.72.0.913120070593.issue12471@psf.upfronthosting.co.za>
Message-ID: <1309771850.09.0.763424317522.issue12471@psf.upfronthosting.co.za>


Renaud Blanch <rndblnch at gmail.com> added the comment:

that was quick!
just a question: is it worth backporting the fix to 2.7?
if this helps, here is a backport for the patch commited to 3.2 <http://hg.python.org/cpython/rev/97707459bb5a>

----------
Added file: http://bugs.python.org/file22563/PyUnicode_Format_TypeError_message.2.7.patch

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

From report at bugs.python.org  Mon Jul  4 11:52:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 09:52:31 +0000
Subject: [issue12429] test_io.check_interrupted_write() sporadic failures on
	FreeBSD 6 on Python 2.7/3.2
In-Reply-To: <1309260227.84.0.740113314895.issue12429@psf.upfronthosting.co.za>
Message-ID: <E1QdfpN-00070o-Po@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a624b86264a4 by Victor Stinner in branch '2.7':
Issue #12429: Skip interrupted write tests on FreeBSD <= 7
http://hg.python.org/cpython/rev/a624b86264a4

New changeset e924e51e9447 by Victor Stinner in branch '3.2':
Issue #12429: Skip interrupted write tests on FreeBSD <= 7
http://hg.python.org/cpython/rev/e924e51e9447

New changeset 79d7bcbe88f6 by Victor Stinner in branch 'default':
null merge 3.2
http://hg.python.org/cpython/rev/79d7bcbe88f6

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 12:18:25 2011
From: report at bugs.python.org (Peter Schuller)
Date: Mon, 04 Jul 2011 10:18:25 +0000
Subject: [issue12487] urllib2.urlopen() returns object missing context manager
In-Reply-To: <1309774705.31.0.473593328364.issue12487@psf.upfronthosting.co.za>
Message-ID: <1309774705.31.0.473593328364.issue12487@psf.upfronthosting.co.za>


New submission from Peter Schuller <peter.schuller at infidyne.com>:

The documentation states it returns a "file-like object". In Python 2.5+ I expect such file-like objects to have a context manager for use with the with statement.

In my particular use-case, the lack comes from urllib.addinfourl but I have not investigated what the possible types returned may be.

----------
components: Library (Lib)
messages: 139746
nosy: scode
priority: normal
severity: normal
status: open
title: urllib2.urlopen() returns object missing context manager
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Jul  4 12:28:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Jul 2011 10:28:58 +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: <1309775338.58.0.989852848563.issue10181@psf.upfronthosting.co.za>


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

In order to have a basis for discussion, I've set up a repo at

    http://hg.python.org/features/pep-3118#memoryview

with an implementation of PyManagedBuffer. The whole test suite
passes, also with refleak counting and Valgrind.


Review is most welcome. If you think that this is roughly what
PyManagedBuffer is supposed to look like, I can add some tests
and documentation.


A couple of remarks:

  o I have used refcounting assumptions that appear to be valid
    for the Python codebase, but that need to be documented.

  o The docs state that if an underlying object supports writable
    views, the memoryview will be readable and writable. I use this
    in PyManagedBuffer_FromObject(). In fact there are tests that
    write to the original exporting object.

  o Releasing a view raises if more than one view is active.

  o get_shape0() is used in memory_length(). This does not seem
    correct if ndim > 1.

  o memory_getbuf() is still not a real getbufferproc, since it
    disregards almost all flags.

  o PyMemoryView_GetContiguous() needs to create a view with an
    underlying PyManagedBuffer. If the obj parameter is already
    a memoryview, the existing PyManagedBuffer has to be used,
    so I just do a check if the requested buffertype agrees with
    view->readonly.

    It would be possible to complicate the code further by having
    a PyMemoryView_FromObjectAndFlags().

  o In the non-contiguous case, PyMemoryView_GetContiguous() creates
    a new buffer, but the returned view does not use that buffer.

----------
hgrepos: +36

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

From report at bugs.python.org  Mon Jul  4 12:29:41 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Jul 2011 10:29:41 +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: <1309775381.87.0.986466471077.issue10181@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file22564/bbe70ca4e0e5.diff

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

From report at bugs.python.org  Mon Jul  4 12:36:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 10:36:14 +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: <1309775774.05.0.763323986253.issue10181@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/issue10181>
_______________________________________

From report at bugs.python.org  Mon Jul  4 12:42:29 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Jul 2011 10:42:29 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309222705.19.0.199391578033.issue10181@psf.upfronthosting.co.za>
Message-ID: <20110704104022.GA13799@sleipnir.bytereef.org>


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

Nick Coghlan <report at bugs.python.org> wrote:
> The reason redirecting all requests to the underlying object doesn't work
> is because repeated calls to getbuffer on mutable objects are allowed to
> return *different* answers. Assume we have a mutable array type that allows
> changes while memory is exported by keeping the old buffer around until all
> references are released. Then we want the following behaviour:
> 
> The builtin bytearray avoids this issue by simply disallowing mutation while
> a buffer is exported, but memoryview needs to cope with arbitrary third party
> objects which may behave like the hypothetical mutable_byte_array().

I find this behavior quite sane. Would it not be an option to make this
a requirement in the PEP? As far as I can see, Numpy also disallows
mutations on exported buffers.

----------

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

From report at bugs.python.org  Mon Jul  4 12:52:45 2011
From: report at bugs.python.org (Yoav Weiss)
Date: Mon, 04 Jul 2011 10:52:45 +0000
Subject: [issue12439] BaseHTTPServer's send_reponse adds extra "\r\n" when
	using HTTPMessage in input
In-Reply-To: <1309722358.59.0.944617906049.issue12439@psf.upfronthosting.co.za>
Message-ID: <CAKrZ8V12Gomxn6O9AND=tVnvAKmrH2+Z=wmpYqkgtPFNy1de1g@mail.gmail.com>


Yoav Weiss <yoav.weiss.fr at gmail.com> added the comment:

Thanks for correcting me. I guess I assumed that the "message" variable is
an HTTPMessage.
Is send_response documented somewhere? I failed to find a reference.

On Sun, Jul 3, 2011 at 9:45 PM, Petri Lehtinen <report at bugs.python.org>wrote:

>
> Petri Lehtinen <petri at digip.org> added the comment:
>
> It seems to me that you're indeed misusing it.
>
> The correct way would be something like this (assuming response is a
> HTTPResponse object from httplib):
>
> self.send_response(response.status)
> for name, value in response.getheaders():
>    self.send_header(name, value)
> self.end_headers()
>
> This is because send_response's second argument is the HTTP's "reason"
> field, i.e. invoking:
>
>    self.send_response(123, 'FOOBAR')
>
> results in
>
>    HTTP/1.1 123 FOOBAR\r\n
>
> to be sent, followed by "Server" and "Date" headers. The second argument is
> not meant to be used for sending headers.
>
> (When the second argument is omitted, a standard reason for the given
> status code is used.)
>
> ----------
> nosy: +petri.lehtinen
> resolution:  -> invalid
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12439>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22565/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12439>
_______________________________________
-------------- next part --------------
Thanks for correcting me. I guess I assumed that the &quot;message&quot; variable is an HTTPMessage.<div>Is send_response documented somewhere? I failed to find a reference.</div><div><br></div><div><br><div class="gmail_quote">
On Sun, Jul 3, 2011 at 9:45 PM, Petri Lehtinen <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>
Petri Lehtinen &lt;<a href="mailto:petri at digip.org">petri at digip.org</a>&gt; added the comment:<br>
<br>
It seems to me that you&#39;re indeed misusing it.<br>
<br>
The correct way would be something like this (assuming response is a HTTPResponse object from httplib):<br>
<br>
self.send_response(response.status)<br>
for name, value in response.getheaders():<br>
 ?? ??self.send_header(name, value)<br>
self.end_headers()<br>
<br>
This is because send_response&#39;s second argument is the HTTP&#39;s &quot;reason&quot; field, i.e. invoking:<br>
<br>
 ?? ??self.send_response(123, &#39;FOOBAR&#39;)<br>
<br>
results in<br>
<br>
 ?? ??HTTP/1.1 123 FOOBAR\r\n<br>
<br>
to be sent, followed by &quot;Server&quot; and &quot;Date&quot; headers. The second argument is not meant to be used for sending headers.<br>
<br>
(When the second argument is omitted, a standard reason for the given status code is used.)<br>
<br>
----------<br>
nosy: +petri.lehtinen<br>
resolution: ??-&gt; invalid<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/issue12439" target="_blank">http://bugs.python.org/issue12439</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Mon Jul  4 12:55:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 10:55:05 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <1309776905.88.0.445794494629.issue9642@psf.upfronthosting.co.za>


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

Patch version 2, more complete: use HAVE_MBCS everywhere.

----------
Added file: http://bugs.python.org/file22566/have_mbcs-2.patch

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

From report at bugs.python.org  Mon Jul  4 12:59:07 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 04 Jul 2011 10:59:07 +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: <1309777147.03.0.276482872267.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

@skrah:

Yes, Numpy exposes only a single buffer per object. Making this a requirement in the PEP would probably be a sane change, as there is probably little real-world need to allow it behave otherwise.

Comment on the patch: it seems you do not track the re-export count in memory_getbuf:

    a = memoryview(obj)
    b = numpy.asarray(a)
    a.release()
    b[0] = 123 # <-- BOOM: the buffer was already released

Could be fixed by Py_INCREF(self->mbuf) in getbuffer and DECREF in releasebuffer. In this design, the only choice is to make the `release()` call to fail. (I had some code for n-dim slicing etc. in my first patch that could be useful to have too; I'll see if I find time to dig them out here.)

----------

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

From report at bugs.python.org  Mon Jul  4 13:26:35 2011
From: report at bugs.python.org (Jonas Wagner)
Date: Mon, 04 Jul 2011 11:26:35 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309778795.84.0.0515895419717.issue12411@psf.upfronthosting.co.za>


Jonas Wagner <veers at gmx.ch> added the comment:

Hi Tal,

Thanks a lot for your feedback.

My primary objective was to increase the test coverage for cgi.py. If it is a problem to have the additional tests in this patch I'm happy to create a new issue with a separate patch. 

The default value for the boundary was an oversight, sorry for that.

You are right regarding the commented out boundary as well, I forgot to refresh the patch. Again, sorry.

Do you think valid_boundary should contain a check to ensure it is a byte object?

----------
Added file: http://bugs.python.org/file22567/cgi-coverage-2.diff

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

From report at bugs.python.org  Mon Jul  4 13:37:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 11:37:14 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <1309779434.46.0.743402446424.issue9642@psf.upfronthosting.co.za>


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

Version 3 of the patch:
 - fix initialization of the filesystem encoding if HAVE_MBCS is not set
 - Python fails on the filesystem encoding if it is unable to get the filesystem encoding instead of using UTF-8
 - reorganize the definition of time_clock() function
 - cleanup how TZNAME_ENCODING is defined in timemodule.c

The change on initfsencoding() should be defined in a separated commit.

----------
Added file: http://bugs.python.org/file22568/have_mbcs-3.patch

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

From report at bugs.python.org  Mon Jul  4 13:43:29 2011
From: report at bugs.python.org (Luke)
Date: Mon, 04 Jul 2011 11:43:29 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>


New submission from Luke <lcampagn at email.unc.edu>:

I have found that when using multiprocessing.Connection objects to pass data between two processes, closing one end of the pipe is not properly communicated to the other end. My expectation was that when calling recv() on the remote end, it should raise EOFError if the pipe has been closed. Instead, the remote recv() blocks indefinitely. This behavior exists on Linux and Cygwin, but NOT on native Windows.

Example:

    import multiprocessing as m

    def fn(pipe):
        print "recv:", pipe.recv()
        print "recv:", pipe.recv()

    if __name__ == '__main__':
        p1, p2 = m.Pipe()
        pr = m.Process(target=fn, args=(p2,))
        pr.start()
        p1.send(1)
        p1.close()  ## should generate EOFError in remote process

----------
messages: 139754
nosy: lcampagn
priority: normal
severity: normal
status: open
title: multiprocessing.Connection does not communicate pipe closure between parent and child
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  4 13:49:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 11:49:05 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <E1QdheC-0007nb-GE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7ce685cda0ae by Victor Stinner in branch 'default':
Issue #9642: Fix filesystem encoding initialization: use the ANSI code page on
http://hg.python.org/cpython/rev/7ce685cda0ae

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 14:03:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 12:03:53 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <E1QdhsW-0000sF-2K@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 75b18b10064f by Victor Stinner in branch 'default':
Issue #9642: Fix the definition of time.clock() on Windows
http://hg.python.org/cpython/rev/75b18b10064f

----------

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

From report at bugs.python.org  Mon Jul  4 14:11:24 2011
From: report at bugs.python.org (Tal Einat)
Date: Mon, 04 Jul 2011 12:11:24 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309781484.14.0.0685260052519.issue12411@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Yes, please submit the other additional tests in a separate issue.

The default value for boundary should surely be b"". A simple test should be added where cgi.parse_multipart() uses the default boundary.

If valid_boundary() is used only for cgi.parse_multipart() then it should be changed to validate that the boundary is a bytes instance (which would also make it simpler). Otherwise (if vaild_boundary() is also used elsewhere) cgi.parse_multipart() should itself check that the boundary is indeed a bytes instance, throwing a TypeError otherwise.

Tip: You should run the relevant tests, making sure they all pass, before submitting a patch. That way you really know that the patch actually works (as far as passing all of the tests).

Thanks for adding more stdlib tests :)

----------

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

From report at bugs.python.org  Mon Jul  4 14:21:09 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Jul 2011 12:21:09 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309777147.03.0.276482872267.issue10181@psf.upfronthosting.co.za>
Message-ID: <20110704121902.GA14216@sleipnir.bytereef.org>


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

Pauli Virtanen <report at bugs.python.org> wrote:
> Comment on the patch: it seems you do not track the re-export count in memory_getbuf:
> 
>     a = memoryview(obj)
>     b = numpy.asarray(a)
>     a.release()
>     b[0] = 123 # <-- BOOM: the buffer was already released

Could you give the exact sequence of events (including the creation of obj)?

For me this works:

Python 3.3a0 (memoryview:bbe70ca4e0e5+, Jul  4 2011, 13:55:55) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> obj = bytearray(b'123456789')
>>> a = memoryview(obj)
>>> b = numpy.asarray(a)
>>> a.release()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: several memoryviews are active
>>> b[0] = 123
>>> b
array([123,  50,  51,  52,  53,  54,  55,  56,  57], dtype=uint8)
>>> del a
>>> b[0] = 224
>>> b
array([224,  50,  51,  52,  53,  54,  55,  56,  57], dtype=uint8)

> (I had some code for n-dim slicing etc. in my first patch that could be
>  useful to have too; I'll see if I find time to dig them out here.)

That would be nice.

----------

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

From report at bugs.python.org  Mon Jul  4 14:26:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 12:26:03 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <E1QdiDs-00037o-AW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 13e6d3cb2ecd by Victor Stinner in branch 'default':
Issue #9642: Uniformize the tests on the availability of the mbcs codec
http://hg.python.org/cpython/rev/13e6d3cb2ecd

----------

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

From report at bugs.python.org  Mon Jul  4 14:26:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 12:26:44 +0000
Subject: [issue9642] #ifdef and mbcs: don't check
	for	defined(HAVE_USABLE_WCHAR_T)
In-Reply-To: <1282219348.43.0.267719038373.issue9642@psf.upfronthosting.co.za>
Message-ID: <1309782404.5.0.018023674565.issue9642@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Jul  4 14:27:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Jul 2011 12:27: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: <1309782447.8.0.987577937699.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It might be worth postponing the multi-dimensional support to a second patch, though. If we can get the buffer lifecycle solid first then that provides a better foundation for any further development.

----------

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

From report at bugs.python.org  Mon Jul  4 14:28:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 12:28:51 +0000
Subject: [issue12452] reuse plistlib in sysconfig;
	deprecation process in plistlib
In-Reply-To: <1309444761.1.0.605266895542.issue12452@psf.upfronthosting.co.za>
Message-ID: <E1QdiGg-0003F4-KK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4f14050a963f by Victor Stinner in branch 'default':
Issue #12452: Plist and Dict are now deprecated
http://hg.python.org/cpython/rev/4f14050a963f

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 14:30:51 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Jul 2011 12:30:51 +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: <1309782651.36.0.102425521749.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As far as the rule of disallowing shape changes while a buffer is exported, I actually think that's a more sane approach as well. However, I've been burned enough times by going "nobody would be insane enough to rely on that, would they?" that I'm seriously reluctant to impose additional backwards incompatible rules on a published spec when it isn't *too* difficult to adjust the infrastructure to better handle the existing complexity.

----------

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

From report at bugs.python.org  Mon Jul  4 14:32:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 12:32:50 +0000
Subject: [issue11859] test_interrupted_write_text() of test_io failed of
	Python 3.3 on FreeBSD 7.2
In-Reply-To: <1302994631.38.0.484484359613.issue11859@psf.upfronthosting.co.za>
Message-ID: <1309782770.57.0.234269923261.issue11859@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul  4 14:51:58 2011
From: report at bugs.python.org (=?utf-8?q?Tiago_Gon=C3=A7alves?=)
Date: Mon, 04 Jul 2011 12:51:58 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1309783918.62.0.781328381975.issue10141@psf.upfronthosting.co.za>


Tiago Gon?alves <tiagogoncalves at ua.pt> added the comment:

There is this "simple" program that can be easily adapted to test the interface. http://old.nabble.com/Socketcan-with-Python-td29286297.html#a29286297

----------
nosy: +ogait87

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

From report at bugs.python.org  Mon Jul  4 15:00:54 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 04 Jul 2011 13:00:54 +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: <1309784454.2.0.501242715317.issue10181@psf.upfronthosting.co.za>


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

[I agree that multi-dimensional support should not be part of this
 patch. I was thinking about creating a separate branch for that.]

Nick Coghlan <report at bugs.python.org> wrote:
> As far as the rule of disallowing shape changes while a buffer is exported, 
> I actually think that's a more sane approach as well. However, I've been 
> burned enough times by going "nobody would be insane enough to rely on that, 
> would they?" that I'm seriously reluctant to impose additional backwards 
> incompatible rules on a published spec when it isn't *too* difficult to 
> adjust the infrastructure to better handle the existing complexity.

Yes, I understand. However, Pauli said earlier:

"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 :)"


That's why I thought that no one could be using this feature at present.


The main problem that have with PyManagedBuffer is that the capabilities
of the original underlying buffer (flags) *at the time of the export* 
aren't stored anywhere.

This makes it hard to respond to specific queries in memory_getbuf()
and PyMemoryObject_GetContiguous(). You can't query the original
object again since it might have changed.

I suppose that an existing memoryview could recompute its own
capabilities by using PyBuffer_IsContiguous() and friends. It
would be much easier though if the original flags were stored
in the buffer by PyObject_GetBuffer().

----------

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

From report at bugs.python.org  Mon Jul  4 15:24:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Jul 2011 13:24:10 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309785850.12.0.459572984447.issue12488@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

That's because the other end of the pipe (p1) is open in the child process (FDs are inherited on fork()).
Just add
p1.close()

at the beginning of fn() and you'll get EOF.
Closing as invalid.

----------
nosy: +neologix
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jul  4 15:26:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Jul 2011 13:26:46 +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: <1309786006.8.0.49279994197.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Nice work with the patch Stefan - I've added a few review comments (including a suggestion on how to deal with the GetContiguous problem).

One idea that review did prompt is that if we aren't going back to the original object for fresh buffer requests, perhaps we should expose the underlying object as a read-only property of the memoryview objects. That way if the original view is unsuitable (e.g. read-only when a writable buffer is needed) it should be straightforward to go back to the underlying object to request something different.

Another question Stefan raised is whether or not PyMemoryView_FromObject should accept a "flags" argument that it passes on to the underlying "getbuffer" call. I'm inclined to say yes - ideally I'd like to *only* expose PyMemoryView and PyManagedBuffer (rather than GetBuffer/ReleaseBuffer) for the limited API, which means accepting the flags argument for the two higher level interfaces.

----------

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

From report at bugs.python.org  Mon Jul  4 15:29:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Jul 2011 13:29: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: <1309786162.81.0.885927262415.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Is there anything stopping us just storing the flags on PyManagedBuffer? It's OK if the construction API requires the flag information in addition to the Py_buffer struct.

----------

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

From report at bugs.python.org  Mon Jul  4 15:29:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jul 2011 13:29:44 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1309786184.23.0.368418967662.issue10141@psf.upfronthosting.co.za>


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


----------
nosy: +neologix, rosslagerwall
versions:  -Python 3.2

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

From report at bugs.python.org  Mon Jul  4 15:52:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 13:52:57 +0000
Subject: [issue12415] Missing: How to checkout the Doc sources
In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>
Message-ID: <1309787577.89.0.691906643068.issue12415@psf.upfronthosting.co.za>


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

We fix bugs in 3.2 and then forward-merge in what will become 3.3, using Mercurial.  Then we apply the same change for 2.7.  More info: http://docs.python.org/devguide

I will commit this change this week.

----------
assignee: docs at python -> eric.araujo
keywords: +patch
stage:  -> patch review

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

From report at bugs.python.org  Mon Jul  4 15:56:22 2011
From: report at bugs.python.org (Luke)
Date: Mon, 04 Jul 2011 13:56:22 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309785850.12.0.459572984447.issue12488@psf.upfronthosting.co.za>
Message-ID: <CACZXET_BrT4UTVG3EUc5b8EGhZM50HD0fML4hLRUticby9LAfA@mail.gmail.com>


Luke <lcampagn at email.unc.edu> added the comment:

That's interesting, thanks for your response.

It is also a bit awkward..
Might I recommend adding a note to the documentation? It is not really
intuitive that each child should need to close the end of the pipe it isn't
using (especially since it is possible to create a child that has no
explicit access to that end of the pipe, even though it has inherited the
file descriptor).

2011/7/4 Charles-Fran??ois Natali <report at bugs.python.org>

>
> Charles-Fran??ois Natali <neologix at free.fr> added the comment:
>
> That's because the other end of the pipe (p1) is open in the child process
> (FDs are inherited on fork()).
> Just add
> p1.close()
>
> at the beginning of fn() and you'll get EOF.
> Closing as invalid.
>
> ----------
> nosy: +neologix
> resolution:  -> invalid
> stage:  -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12488>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22569/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12488>
_______________________________________
-------------- next part --------------
That&#39;s interesting, thanks for your response.<div><br></div><div>It is also a bit awkward..??<div>Might I recommend adding a note to the documentation? It is not really intuitive that each child should need to close the end of the pipe it isn&#39;t using (especially since it is possible to create a child that has no explicit access to that end of the pipe, even though it has inherited the file descriptor).??<br>

<div><br><br><div class="gmail_quote">2011/7/4 Charles-Fran??ois Natali <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Charles-Fran??ois Natali &lt;<a href="mailto:neologix at free.fr">neologix at free.fr</a>&gt; added the comment:<br>
<br>
That&#39;s because the other end of the pipe (p1) is open in the child process (FDs are inherited on fork()).<br>
Just add<br>
p1.close()<br>
<br>
at the beginning of fn() and you&#39;ll get EOF.<br>
Closing as invalid.<br>
<br>
----------<br>
nosy: +neologix<br>
resolution: ??-&gt; invalid<br>
stage: ??-&gt; committed/rejected<br>
status: open -&gt; closed<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/issue12488" target="_blank">http://bugs.python.org/issue12488</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div></div></div>

From report at bugs.python.org  Mon Jul  4 16:04:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 14:04:30 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309788270.64.0.32860095671.issue12043@psf.upfronthosting.co.za>


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

-   If *symlinks* is true, symbolic links in the source tree are
+   If *symlinks* is ``True``, symbolic links in the source tree are

I?m not sure about that change.  It may be on purpose that lower-case true is used, given that the code will accept anything that evaluates to True in a boolean context, but does not strictly requires a bool instance.

See also #7969 for another shutil doc bug.

----------

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

From report at bugs.python.org  Mon Jul  4 16:11:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 14:11:02 +0000
Subject: [issue12391] packaging install fails to clean up temp files
In-Reply-To: <1308815016.03.0.685993126745.issue12391@psf.upfronthosting.co.za>
Message-ID: <1309788662.12.0.695151862591.issue12391@psf.upfronthosting.co.za>


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

1: Agreed.

2 and 3: Alexis most probably added that behavior as a convenience.  Unless I?m mistaken, the point of $TMP/$TMPDIR is that the OS itself will clean it up, for example on shutdown, so programs that leave stuff here are not strictly wrong.  However, given the realities of Windows behavior (I recall seeing ?temporary? directories with tons of stuff never cleaned up) and the low cost of a change (?It's not asking a lot to be given an explicit path to install to? +1), my opinion is that we should take your patch as it is.

----------
stage:  -> commit review

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

From report at bugs.python.org  Mon Jul  4 16:33:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 14:33:07 +0000
Subject: [issue793069] Add --remove-source option
Message-ID: <1309789987.47.0.0693316354642.issue793069@psf.upfronthosting.co.za>


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

I am now -1: I don?t see this feature as particularly useful, and it would increase the maintenance cost.  If nobody speaks up to defend it, I will reject it.

----------
versions: +Python 3.3 -3rd party

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

From report at bugs.python.org  Mon Jul  4 16:35:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 14:35:15 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1309790115.36.0.617445186306.issue4673@psf.upfronthosting.co.za>


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

distutils2/packaging now provides a remove function and a pysetup remove command.

----------
dependencies:  -distutils removing old files, deleting unneeded old files from installed location.
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -3rd party

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

From report at bugs.python.org  Mon Jul  4 16:36:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 14:36:48 +0000
Subject: [issue5342] packaging: add tests for old versions cleanup on update
In-Reply-To: <1235256230.9.0.667035234316.issue5342@psf.upfronthosting.co.za>
Message-ID: <1309790208.11.0.610412803631.issue5342@psf.upfronthosting.co.za>


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

I?m renaming this to make the status clearer: it?s about adding tests.

----------
keywords: +easy
nosy: +alexis
stage:  -> test needed
title: distutils removing old files, deleting unneeded old files from installed location. -> packaging: add tests for old versions cleanup on update
type: feature request -> behavior
versions: +Python 3.3 -3rd party

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

From report at bugs.python.org  Mon Jul  4 16:36:56 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 04 Jul 2011 14:36:56 +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: <1309790216.55.0.139193640866.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

@skrah:

Ahh, this always happens when I don't run it :)  But my point stands -- the reason why it does not crash with Numpy is that Numpy calls PyMemoryView_FromObject to obtain a new memoryview and then uses PyMemoryView_GET_BUFFER. Along this code path the refcount of self->mbuf gets properly incremented, as it's explicitly done in PyMemoryView_FromObject. However, if you have a custom object Foo which just calls `PyObject_GetBuffer`, and then do the same sequence

    a = memoryview(whatever)
    b = Foo(a)  # --> only grabs the buffer with PyObject_GetBuffer
    a.release() # --> will invalidate the buffer
    b.mogrify_buffer_contents()  # --> boom

Here, the buffer is released too early, as the refcount of `self->mbuf` is not incremented during the `PyObject_GetBuffer` call.

> Is there anything stopping us just storing the flags on
> PyManagedBuffer?

Slicing memoryviews can invalidate the contiguity flags, and no-strides flags, so some checks are still probably needed in `memory_getbuf`.

> It's OK if the construction API requires the flag
> information in addition to the Py_buffer struct. 

This would be useful, yes.

----------

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

From report at bugs.python.org  Mon Jul  4 16:38:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 14:38:03 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1309790283.61.0.423848869501.issue10571@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: needs patch -> test needed
versions: +Python 3.3

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

From report at bugs.python.org  Mon Jul  4 16:38:20 2011
From: report at bugs.python.org (Thomas Guettler)
Date: Mon, 04 Jul 2011 14:38:20 +0000
Subject: [issue12489] email.errors.HeaderParseError if base64url is used
In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za>
Message-ID: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

from email.header import decode_header
decode_header('=?iso-8859-1?B?QW5tZWxkdW5nIE5ldHphbnNjaGx1c3MgU_xkcmluZzNwLmpwZw==?=')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/email/header.py", line 101, in decode_header
    raise HeaderParseError
email.errors.HeaderParseError

thunderbird is able to decode the header:
"Anmeldung Netzanschluss S?dring3p.jpg"

According to Peter Otten base64url encoding was used:

My question in the newsgroup:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/9cf9ccd4109481cc/9f76bd627676b5f1?show_docid=9f76bd627676b5f1

----------
components: Library (Lib)
messages: 139776
nosy: guettli
priority: normal
severity: normal
status: open
title: email.errors.HeaderParseError if base64url is used
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  4 16:38:50 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 04 Jul 2011 14:38:50 +0000
Subject: [issue12391] packaging install fails to clean up temp files
In-Reply-To: <1309788662.12.0.695151862591.issue12391@psf.upfronthosting.co.za>
Message-ID: <1309790329.53490.YahooMailRC@web25805.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

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

> 2 and 3: Alexis most probably added that  behavior as a convenience.  Unless 
>I?m mistaken, the point of $TMP/$TMPDIR  is that the OS itself will clean it up, 
>for example on shutdown, so programs  that leave stuff here are not strictly 
>wrong.  However, given the realities  of Windows behavior (I recall seeing 
>?temporary? directories with tons of stuff  never cleaned up) and the low cost 
>of a change (?It's not asking a lot to be  given an explicit path to install to? 
>+1), my opinion is that we should take  your patch as it is.

Great. Although /tmp is cleaned up on restart (on Linux at least), waiting for 
that can lead to problems. For example, I came across this problem when I (for 
test purposes) installed every single one of the 400+ packages on PyPI which 
claim to be Py3 compatible, into a virtual env, using "pysetup3 install". I then 
noticed some (slight) performance slowdown and sudden disappearance of free disk 
space ... it was all those archives (and their unpacked contents) in /tmp that 
was the reason.

----------

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

From report at bugs.python.org  Mon Jul  4 16:39:12 2011
From: report at bugs.python.org (Thomas Guettler)
Date: Mon, 04 Jul 2011 14:39:12 +0000
Subject: [issue12489] email.errors.HeaderParseError if base64url is used
In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za>
Message-ID: <1309790352.52.0.999375734103.issue12489@psf.upfronthosting.co.za>


Thomas Guettler <guettli at thomas-guettler.de> added the comment:

This happens on Python3:
root at ubuntu1004devel64:~# python3
Python 3.1.2 (r312:79147, Sep 27 2010, 09:57:50) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.header import decode_header
>>> decode_header('=?iso-8859-1?B?QW5tZWxkdW5nIE5ldHphbnNjaGx1c3MgU_xkcmluZzNwLmpwZw==?=')
Traceback (most recent call last):
  File "/usr/lib/python3.1/email/header.py", line 98, in decode_header
    word = email.base64mime.decode(encoded_string)
  File "/usr/lib/python3.1/email/base64mime.py", line 112, in decode
    return a2b_base64(string.encode('raw-unicode-escape'))
binascii.Error: Incorrect padding

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.1/email/header.py", line 100, in decode_header
    raise HeaderParseError('Base64 decoding error')
email.errors.HeaderParseError: Base64 decoding error

----------

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

From report at bugs.python.org  Mon Jul  4 17:49:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 15:49:50 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <E1QdlPB-0002ua-7B@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e07b331bf489 by Victor Stinner in branch '3.2':
Issue #12469: Run "wakeup" signal tests in subprocess to run the test in a
http://hg.python.org/cpython/rev/e07b331bf489

New changeset b9de5e55f798 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12469: Run wakeup and pending signal tests in a subprocess
http://hg.python.org/cpython/rev/b9de5e55f798

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 18:06:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 16:06:40 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309795600.79.0.636488108103.issue12469@psf.upfronthosting.co.za>


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

Commits e07b331bf489 and b9de5e55f798 run wakeup and pending signal tests in a subprocess to avoid border effects with threads. It should make these tests more reliable, not only on FreeBSD 6.

PendingSignalsTests now use os.kill() instead of signal.pthread_kill() in most tests (except test_pthread_kill and test_pthread_kill_main_test). We don't need pthread_kill() here anymore because we know that we have exactly one thread. I prefer to use the simple and common os.kill(), and only use pthread_kill in pthread_kill tests.

I'm not proud of that, but I added a workaround for the kernel bug (create a dummy thread, just to initialize the pthread library) in test_pthread_kill(). I don't know how to write a (simple and) reliable test on FreeBSD 6 without this workaround. But I prefer to use a workaround than skipping the test.

I don't think that it would be revelant to use the workaround in test_pthread_kill_main_test(). I chose to skip the test on FreeBSD 6, even if the test was written for this OS (issue #12392).

----------

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

From report at bugs.python.org  Mon Jul  4 18:06:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 16:06:54 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <E1Qdlfh-0004Av-7f@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7eef821ab20d by Victor Stinner in branch 'default':
Issue #12469: replace assertions by explicit if+raise
http://hg.python.org/cpython/rev/7eef821ab20d

----------

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

From report at bugs.python.org  Mon Jul  4 18:14:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 16:14:25 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309796065.66.0.362039204481.issue12469@psf.upfronthosting.co.za>


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

TODO:
 - check_signum() of WakeupSignalsTests.check_wakeup(): remove set() to check the order of the received signals (revert 29e08a98281d)
 - run test_main(), test_itimer_virtual() and test_itimer_prof() in subprocesses
 - fix/skip test_faulthandler on FreeBSD 6
 - revert 024827a9db64 (thread initialization)

----------

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

From report at bugs.python.org  Mon Jul  4 18:15:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 16:15:32 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1309796132.01.0.52542865748.issue12398@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/issue12398>
_______________________________________

From report at bugs.python.org  Mon Jul  4 18:16:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 16:16:35 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1303393354.57.0.483160590848.issue11898@psf.upfronthosting.co.za>
Message-ID: <1309796195.98.0.682597165795.issue11898@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg134878

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

From report at bugs.python.org  Mon Jul  4 18:17:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 16:17:26 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309796246.07.0.925895649437.issue12469@psf.upfronthosting.co.za>


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

> TODO: run test_main(), test_itimer_virtual() and test_itimer_prof()
> in subprocesses

Another TODO: check if test_sigtimedwait_poll() still fails after reverting 024827a9db64 (thread initialization).

----------

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

From report at bugs.python.org  Mon Jul  4 18:19:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 16:19:19 +0000
Subject: [issue12439] BaseHTTPServer's send_reponse adds extra "\r\n" when
	using HTTPMessage in input
In-Reply-To: <1309340125.43.0.831188381846.issue12439@psf.upfronthosting.co.za>
Message-ID: <1309796359.96.0.888654311512.issue12439@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22565/unnamed

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

From report at bugs.python.org  Mon Jul  4 18:20:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 16:20:41 +0000
Subject: [issue12439] BaseHTTPServer's send_reponse adds extra "\r\n" when
	using HTTPMessage in input
In-Reply-To: <1309340125.43.0.831188381846.issue12439@psf.upfronthosting.co.za>
Message-ID: <1309796441.22.0.222423387806.issue12439@psf.upfronthosting.co.za>


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

See http://docs.python.org/dev/library/http.server#http.server.BaseHTTPRequestHandler.send_response

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

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

From report at bugs.python.org  Mon Jul  4 18:23:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 16:23:57 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1309796637.6.0.0385582316475.issue12486@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, haypo
type:  -> feature request
versions: +Python 3.3

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

From report at bugs.python.org  Mon Jul  4 18:26:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Jul 2011 16:26:57 +0000
Subject: [issue12485] textwrap.wrap: add control for custom length and orphans
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1309796817.66.0.484677683972.issue12485@psf.upfronthosting.co.za>


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

Hi!  Thanks for the report and patch.  Are your two requests related?  If not, it would be best to open two reports.

----------
components: +Library (Lib) -Extension Modules
keywords: +needs review
nosy: +eric.araujo
stage:  -> patch review
title: Improvement of textwrap module -> textwrap.wrap: add control for custom length and orphans
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Mon Jul  4 18:34:50 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Jul 2011 16:34:50 +0000
Subject: [issue12487] urllib2.urlopen() returns object missing context manager
In-Reply-To: <1309774705.31.0.473593328364.issue12487@psf.upfronthosting.co.za>
Message-ID: <1309797290.81.0.763268838639.issue12487@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/issue12487>
_______________________________________

From report at bugs.python.org  Mon Jul  4 18:55:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Jul 2011 16:55:27 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1309786184.27.0.443142198349.issue10141@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2GF9yt+Vcys6N8sTDDVBUHw9gbZkVTrXW6fgzcrE5Tdg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The patch looks good to me.
A couple remarks:
- could you please post it as a Mercurial diff? (it makes it easier to
review and apply)

@@ -1151,6 +1151,25 @@ makesockaddr(int sockfd, struct sockaddr
 	}

+               return Py_BuildValue("sh",
+                                    ifname,
+                                    a->can_family);

1) a->can_family would be better as a 'i' to be consistent with the
rest of the code

2) you should use the FS encoding for the interface name, e.g.

               return Py_BuildValue("O&i",
                                    PyUnicode_DecodeFSDefault
                                    ifname,
                                    a->can_family);

(you can have a look at socket_if_nameindex for an example).

@@ -1486,6 +1505,43 @@ getsockaddrarg(PySocketSockObject *s, Py

                       if (!PyArg_ParseTuple(args, "s", &interfaceName))
                               return 0;

3) same thing here, you should use
                       if (!PyArg_ParseTuple(args, "O&", PyUnicode_FSConverter,
                                                            &interfaceName))
                               return 0;

(see socket_if_nametoindex for an example)

4)
@@ -1486,6 +1505,43 @@ getsockaddrarg(PySocketSockObject *s, Py

+                       if (!strcmp(interfaceName, "any")) {
+                               ifr.ifr_ifindex = 0;

To be consistent with the convention used IPv4/IPv6
INADDR_ANY/in6addr_any, I would prefer if you replaced the any
interface name by "" (empty string)

5)
@@ -69,6 +69,20 @@ typedef int socklen_t;

+#ifdef HAVE_LINUX_CAN_H
+#include <linux/can.h>
+#ifndef PF_CAN
+# define PF_CAN 29
+#endif
+#ifndef AF_CAN
+# define AF_CAN PF_CAN
+#endif
+#endif

I don't see how PF_CAN or AF_CAN could not be defined lin <linux/can.h>.
And if they're not defined, it's probably not a good idea to define
them arbitrarily...

6)
+#ifdef HAVE_LINUX_CAN_H
+       struct sockaddr_can* can;
+#endif

it should be struct sockaddr_can can here, not a pointer.

7)
- you should update Doc/library/socket.rst

8)
- could you add a test for SocketCan in Lib/test/socket.py ?
It would be nice to have a basic test which can be run on all the
kernels supporting PF_CAN (typically just creating a socket, binding
to it and closing it), and another more complete test if there's a CAN
interface (sending and receiving a packet, probably using the
loopback).
Take into account that SOCK_RAW are priviledged and restricted to root
or CAP_SYS_RAW.

----------

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

From report at bugs.python.org  Mon Jul  4 18:56:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Jul 2011 16:56:55 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309798615.5.0.606989152464.issue12043@psf.upfronthosting.co.za>


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

Yep. The parts changing true/false to ``True``/``False`` should not be committed.

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

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

From report at bugs.python.org  Mon Jul  4 18:57:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Jul 2011 16:57:32 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309798652.91.0.114511446627.issue12488@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Well, in this regard it behaves like a Unix pipe/socket (in the duplex case it's implemented with a Unix domain socket), so I find it quite natural (of course, you have to know about FD inheritance upon fork()).
I'm not convinced it's necessary, Antoine any thought on that?

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Jul  4 18:58:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jul 2011 16:58:06 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309798686.59.0.135526717158.issue12488@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file22569/unnamed

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

From report at bugs.python.org  Mon Jul  4 19:07:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jul 2011 17:07:21 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309799241.29.0.105010421715.issue12488@psf.upfronthosting.co.za>


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

Well, I think it deserves a comment in the documentation that behaviour of Pipes and Queues when one of the process terminates is undefined and implementation-dependent.

By the way, there's internal support in 3.3 to reliably detect killed children, and it's used by concurrent.futures: http://docs.python.org/dev/library/concurrent.futures.html#concurrent.futures.BrokenProcessPool. However, I'm not sure there's an easy way to detect a killed master process from one of the worker processes.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul  4 19:07:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Jul 2011 17:07:50 +0000
Subject: [issue12413] make faulthandler dump traceback of child processes
In-Reply-To: <1309119059.31782.12.camel@marge>
Message-ID: <CAH_1eM1DBXa970Q+pQD4szRGMnkMDOu+oJbYSX9xDxN-41CxrQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> subprocess doesn't use a shell by default, and I don't think that
> multiprocessing uses a shell to start Python.
>

No, but we precisely want subprocess/multiprocessing-created processes
to be in the same process group.

> To simplify the implementation, I propose to patch multiprocessing
> and/or subprocess to register the pid of the child process in a list in
> the faulthandler module.
>
> It would be better if these modules unregister pid when a subprocess
> exits, but it's not mandatory. We can send a signal to a non existant
> process. In the worst case, on a heavy loaded computer, another process
> may get the same pid, but it's unlikely. I'm quite sure that
> multiprocessing and subprocess already handle the subprocess exit, so it
> should be quite simply to add a hook.
>

It'll be intrusive and error-prone: for example, you'll have to reset
this list upon fork().
And sending a signal to an unrelated process is risky, no?

>> > subprocess can execute any program, not only Python.
>> > Send an arbitrary signal to a child process can cause issues.
>> Well, faulthandler is disabled by default, no ?
>
> Yes, but I prefer to interfer with unrelated processes if it's possible.
>

Well, those processes are started by subprocess, and this would be
enabled only on demand. I find it less risky than sending a signal to
a completely unrelated process.

> faulthandler.enable() installs a signal handler for SIGSEGV, SIGBUS,
> SIGILL and SIGABRT signals. (SIGKILL cannot be handled by the
> application.)
>

We could use one of these signals.

----------

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

From report at bugs.python.org  Mon Jul  4 19:11:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Jul 2011 17:11:11 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309799471.09.0.549711544355.issue12488@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Alright.
Luke, if you're motivated, feel free to provide a patch.
The relevant file is Doc/library/multiprocessing.rst.

----------

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

From report at bugs.python.org  Mon Jul  4 19:15:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Jul 2011 17:15:14 +0000
Subject: [issue12488] multiprocessing.Connection does not communicate pipe
	closure between parent and child
In-Reply-To: <1309779809.62.0.10199189289.issue12488@psf.upfronthosting.co.za>
Message-ID: <1309799714.32.0.356530505043.issue12488@psf.upfronthosting.co.za>


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

By the way, if you don't want children processes to continue running when the master exits, just make them daemonic processes (by adding "daemon=True" to the Process() constructor call).

----------

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

From report at bugs.python.org  Mon Jul  4 19:16:25 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 04 Jul 2011 17:16:25 +0000
Subject: [issue12489] email.errors.HeaderParseError if base64url is used
In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za>
Message-ID: <1309799785.72.0.484867649037.issue12489@psf.upfronthosting.co.za>


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

This gives the correct result:
decode_header('=?iso-8859-1?B?QW5tZWxkdW5nIE5ldHphbnNjaGx1c3MgU/xkcmluZzNwLmpwZw==?=')
(I replaced _ with /)

The header was probably generated by a variant of the base64 encoding, like this one: http://www.doughellmann.com/PyMOTW/base64/#url-safe-variations

Does this header comes from a real message? How was it generated?

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Mon Jul  4 19:19:01 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Mon, 04 Jul 2011 17:19:01 +0000
Subject: [issue12391] packaging install fails to clean up temp files
In-Reply-To: <1308815016.03.0.685993126745.issue12391@psf.upfronthosting.co.za>
Message-ID: <1309799941.95.0.134475014218.issue12391@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

I'm +1 on applying this patch as well. Removing files in the tmp directory is far better than letting the OS doing so.

----------

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

From report at bugs.python.org  Mon Jul  4 19:54:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 17:54:52 +0000
Subject: [issue12467] test_threading.test_6_daemon_threads(): Assertion
	failed: PyUnicode_Check(*filename), file ..\Python\_warnings.c,
	line 501
In-Reply-To: <1309526483.44.0.248959975063.issue12467@psf.upfronthosting.co.za>
Message-ID: <E1QdnMA-0003af-WD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 861b483e88d9 by Victor Stinner in branch '3.2':
Issue #12467: warnings: fix a race condition if a warning is emitted at
http://hg.python.org/cpython/rev/861b483e88d9

----------

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

From report at bugs.python.org  Mon Jul  4 19:59:48 2011
From: report at bugs.python.org (Kamil Kisiel)
Date: Mon, 04 Jul 2011 17:59:48 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1309802388.55.0.298694497229.issue12423@psf.upfronthosting.co.za>


Kamil Kisiel <kamil at kamilkisiel.net> added the comment:

Here's my proposed patch for the documentation, against the head of the 2.7 branch.

----------
keywords: +patch
Added file: http://bugs.python.org/file22570/os.rst.patch

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

From report at bugs.python.org  Mon Jul  4 20:03:05 2011
From: report at bugs.python.org (Julian)
Date: Mon, 04 Jul 2011 18:03:05 +0000
Subject: [issue12487] urllib2.urlopen() returns object missing context manager
In-Reply-To: <1309774705.31.0.473593328364.issue12487@psf.upfronthosting.co.za>
Message-ID: <1309802585.9.0.470590105923.issue12487@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

You probably should bring this up again on #4972 which is being worked on.


(and for the immediate future you have contextlib.closing too in case you hadn't seen it already)

----------
nosy: +Julian

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

From report at bugs.python.org  Mon Jul  4 20:44:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 18:44:34 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <E1Qdo8F-0001HL-MT@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d442c313536b by Senthil Kumaran in branch '3.2':
issue10403 - Let's not use members anymore. Use 'attribute' where it denotes attribute and 'methods' where it denotes methods. Context should clarify usage.
http://hg.python.org/cpython/rev/d442c313536b

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Jul  4 20:51:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 18:51:18 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <E1QdoEm-0002FD-Dq@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d442c313536b by Senthil Kumaran in branch '3.2':
issue10403 - Let's not use members anymore. Use 'attribute' where it denotes attribute and 'methods' where it denotes methods. Context should clarify usage.
http://hg.python.org/cpython/rev/d442c313536b

----------

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

From report at bugs.python.org  Mon Jul  4 21:41:37 2011
From: report at bugs.python.org (Nir Aides)
Date: Mon, 04 Jul 2011 19:41:37 +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: <1309808497.69.0.0743071616941.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> Sorry, I fail to see how the "import graph" is related to the correct
> lock acquisition order. Some locks are created dynamically, for
> example.

Import dependency is a reasonable heuristic to look into for inter-module locking order. 

The rational is explained in the following pthread_atfork man page:
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
"A higher-level package may acquire locks on its own data structures before invoking lower-level packages. Under this scenario, the order specified for fork handler calls allows a simple rule of initialization for avoiding package deadlock: a package initializes all packages on which it depends before it calls the pthread_atfork() function for itself."

(The rational section is an interpretation which is not part of the standard)

A caveat is that since Python is an object oriented language it is more common than with C that code from a higher level module will be invoked by code from a lower level module, for example by calling an object method that was over-ridden by the higher level module - this actually happens in the logging module (emit method).

> That's why I asked for a specific API: when do you register a handler?
> When are they called? When are they reset?

Read the pthread_atfork man page.

> The whole point of atfork is to avoid breaking invariants and
> introduce invalid state in the child process. If there is one thing we
> want to avoid, it's precisely reading/writting corrupted data from/to
> files, so eluding the I/O problem seems foolish to me.

Please don't use insulting adjectives. 
If you think I am wrong, convincing me logically will do.

you can "avoid breaking invariants" using two different strategies:
1) Acquire locks before the fork and release/reset them after it.
2) Initialize the module to some known state after the fork.

For some (most?) modules it may be quite reasonable to initialize the module to a known state after the fork without acquiring its locks before the fork; this too is explained in the pthread_atfork man page:
"Alternatively, some libraries might be able to supply just a child routine that reinitializes the mutexes in the library and all associated states to some known value (for example, what it was when the image was originally executed)."

> > A  "critical section" lock that protects in-memory data should not be held for long.
>
> Not necessarily. See for example I/O locks and logging module, which
> hold locks until I/O completion.

Oops, I have always used the term "critical section" to describe a lock that protects data state as tightly as possible, ideally not even across function calls but now I see the Wikipedia defines one to protect any resource including IO.

The logging module locks the entire emit() function which I think is wrong. 
It should let the derived handler take care of locking when it needs to, if it needs to at all.

The logging module is an example for a module we should reinitialize after the fork without locking its locks before the fork.

----------

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

From report at bugs.python.org  Mon Jul  4 21:50:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 19:50:23 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <E1Qdp9w-0006kk-SC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b8f5da066782 by Senthil Kumaran in branch '2.7':
Fix closes issue10403 - Let's not use members anymore.
http://hg.python.org/cpython/rev/b8f5da066782

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

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

From report at bugs.python.org  Mon Jul  4 22:42:12 2011
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Mon, 04 Jul 2011 20:42:12 +0000
Subject: [issue12490] Documentation for itertools.chain.from_iterable is
	incorrect
In-Reply-To: <1309812132.83.0.229828200889.issue12490@psf.upfronthosting.co.za>
Message-ID: <1309812132.83.0.229828200889.issue12490@psf.upfronthosting.co.za>


New submission from Rodolpho Eckhardt <rodolpho.eckhardt at gmail.com>:

The documentation at http://docs.python.org/py3k/library/itertools.html#itertools.chain and http://docs.python.org/library/itertools.html#itertools.chain is inconsistent.

At the definition of the class it states that itertools.chain.from_iterable can receive one iterable "Gets chained inputs from a single iterable argument that is evaluated lazily.", but then it contradicts itself by using the following example:

@classmethod
def from_iterable(iterables):
    # chain.from_iterable(['ABC', 'DEF']) --> A B C D E F
    for it in iterables:
        for element in it:
            yield element

This example could lead the reader to believe this alternative constructor can receive multiple iterable objects, when in fact it can receive only one.

----------
assignee: docs at python
components: Documentation
messages: 139802
nosy: RodolphoEckhardt, docs at python
priority: normal
severity: normal
status: open
title: Documentation for itertools.chain.from_iterable is incorrect
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jul  4 22:44:03 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 04 Jul 2011 20:44:03 +0000
Subject: [issue12411] cgi.parse_multipart is broken on 3.x
In-Reply-To: <1309014548.2.0.906650270303.issue12411@psf.upfronthosting.co.za>
Message-ID: <1309812243.25.0.70363772737.issue12411@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

When the FieldStorage class was fixed there was a discussion in issue 4953 about the module-level functions parse() and parse_multipart(). The code was very similar to methods of the FieldStorage class so the idea was to use FieldStorage inside the functions

The patch proposed in issue 11066 replaced the code in parse_multipart by just :

def parse_multipart(fp, pdict):
    return FieldStorage(fp,environ=pdict)

Did anyone test it ?

----------

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

From report at bugs.python.org  Mon Jul  4 22:48:12 2011
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Mon, 04 Jul 2011 20:48:12 +0000
Subject: [issue12490] Documentation for itertools.chain.from_iterable is
	incorrect
In-Reply-To: <1309812132.83.0.229828200889.issue12490@psf.upfronthosting.co.za>
Message-ID: <1309812492.04.0.934773868607.issue12490@psf.upfronthosting.co.za>


Rodolpho Eckhardt <rodolpho.eckhardt at gmail.com> added the comment:

My mistake reading the documentation.
Sorry, closing this issue.

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

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

From report at bugs.python.org  Mon Jul  4 22:48:37 2011
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Mon, 04 Jul 2011 20:48:37 +0000
Subject: [issue12490] Documentation for itertools.chain.from_iterable is
	incorrect
In-Reply-To: <1309812132.83.0.229828200889.issue12490@psf.upfronthosting.co.za>
Message-ID: <1309812517.32.0.232585676712.issue12490@psf.upfronthosting.co.za>


Changes by Rodolpho Eckhardt <rodolpho.eckhardt at gmail.com>:


----------
nosy:  -docs at python
resolution:  -> invalid

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

From report at bugs.python.org  Mon Jul  4 22:55:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 20:55:48 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <E1QdqBH-0002mc-Iq@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 34061f0d35ba by Victor Stinner in branch 'default':
Issue #12469: partial revert of 024827a9db64, freebsd6 thread initialization
http://hg.python.org/cpython/rev/34061f0d35ba

----------

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

From report at bugs.python.org  Mon Jul  4 22:57:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 20:57:58 +0000
Subject: [issue12392] pthread_kill() doesn't work on the main thread on
	FreeBSD6
In-Reply-To: <1308869761.72.0.972861691614.issue12392@psf.upfronthosting.co.za>
Message-ID: <1309813078.1.0.781626235611.issue12392@psf.upfronthosting.co.za>


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

As discussed in issue #12469, the commit 024827a9db64 makes things worse: it changes the behaviour of many functions related to signal handling (e.g. sigwait()) just to be able to use pthread_kill() on the main thread. I reverted the patch: commit 34061f0d35ba.

----------

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

From report at bugs.python.org  Mon Jul  4 23:09:07 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Jul 2011 21:09:07 +0000
Subject: [issue12487] urllib2.urlopen() returns object missing context manager
In-Reply-To: <1309774705.31.0.473593328364.issue12487@psf.upfronthosting.co.za>
Message-ID: <1309813747.57.0.365826857151.issue12487@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

It should be documented that in 2.x series the file-like object does not support context management protocol. I have added the superseder issue number, please see the note as if you really want in 2.x, how you can have it using contextlib and in 3.x the context management protocol support is available.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> URLopener should support context manager protocol

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

From report at bugs.python.org  Mon Jul  4 23:22:47 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Jul 2011 21:22:47 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309808497.69.0.0743071616941.issue6721@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2_DEF4WZr04GA=ng7TUNfhLhxuqWF4ZPVAfo7YtSej1g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

[...]
> A caveat is that since Python is an object oriented language it is more common than with C that code from a higher level module will be invoked by code from a lower level module, for example by calling an object method that was over-ridden by the higher level module - this actually happens in the logging module (emit method).

Exactly. That's why registering atfork() handler in independent
modules can - and will - lead to deadlocks, if we get the order wrong.
Also, most locks are allocated dynamically (at the same time as the
object they protect), so the import order is not really relevant here.
Furthermore, there's not a strict ordering between the modules: how is
bz2 compared to loglib, for example?

>
>> That's why I asked for a specific API: when do you register a handler?
>> When are they called? When are they reset?
>
> Read the pthread_atfork man page.
>

No, it won't do it, since when an object - and its protecting lock -
is deallocated, the related atfork handler must be removed, for
example. You might handle this with wearefs, but that's definitely
something not accounted for by the pthread_atfork standard API.

>> The whole point of atfork is to avoid breaking invariants and
>> introduce invalid state in the child process. If there is one thing we
>> want to avoid, it's precisely reading/writting corrupted data from/to
>> files, so eluding the I/O problem seems foolish to me.
>
> Please don't use insulting adjectives.
> If you think I am wrong, convincing me logically will do.
>

I'm sorry if that sounded insulting to you, it was really
unintentional (English is not my mother tongue).

> you can "avoid breaking invariants" using two different strategies:
> 1) Acquire locks before the fork and release/reset them after it.
> 2) Initialize the module to some known state after the fork.
>
> For some (most?) modules it may be quite reasonable to initialize the module to a known state after the fork without acquiring its locks before the fork; this too is explained in the pthread_atfork man page:
> "Alternatively, some libraries might be able to supply just a child routine that reinitializes the mutexes in the library and all associated states to some known value (for example, what it was when the image was originally executed)."
>

The most problematic place is the I/O layer, since those are the locks
held longer (see for example issue #7123). And I'm not sure we can
simply reinit the I/O object after fork() without corrupting or losing
data.
But this approach (reinitializing after fork()) works well most of the
time, and is actually already used in multiple places (threading and
multiprocessing modules, and probably others).

> Oops, I have always used the term "critical section" to describe a lock that protects data state as tightly as possible, ideally not even across function calls but now I see the Wikipedia defines one to protect any resource including IO.
>

Yes, that's one peculiarity of Python locks.
Another one is that a lock can be released by a process other than the
one who acquired it.

> The logging module locks the entire emit() function which I think is wrong.
> It should let the derived handler take care of locking when it needs to, if it needs to at all.
>
> The logging module is an example for a module we should reinitialize after the fork without locking its locks before the fork.

It's possible.

Like I said earlier in this thread, I'm not at all opposed to the
atfork mechanism. I'm actually in favor of it, the first reason being
that we could factorize the various ad-hoc atfork handlers scattered
through the standard library.
My point is just that it's not as simple as it sounds because of
long-held locks, and that we've got to be really careful because of
inter-module dependencies.

Would you like to work on a patch to add an atfork mechanism?

----------

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

From report at bugs.python.org  Mon Jul  4 23:24:35 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Jul 2011 21:24:35 +0000
Subject: [issue12491] Update glossary documentation for the term 'attribute'
In-Reply-To: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>
Message-ID: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>


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

Update the term 'attribute' in the glossary http://docs.python.org/dev/glossary.html#term-attribute so that the reader can understand that the term attribute in Python can mean both 'data-attribute' and a 'callable' method.

----------
assignee: docs at python
components: Documentation
messages: 139809
nosy: docs at python, orsenthil
priority: normal
severity: normal
status: open
title: Update glossary documentation for the term 'attribute'
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul  4 23:48:38 2011
From: report at bugs.python.org (Juan Gonzalez)
Date: Mon, 04 Jul 2011 21:48:38 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>


New submission from Juan Gonzalez <juan.gonzalez at ti.com>:

Something really weird going on in python find() string function.  When I call <string>.find() and python returns -1 it crashes when compared against 0 using the ">" operator.

The statement in which crash condition occurs is the following:

    if url.find(str) > 0:
        print "RSS Item:", url
	break; 

However, if I change the statement to be "<" instead it does not crash.
The error that the python compiler reports is:

AttributeError: 'int' object has no attribute 'find'

My version of python is:

tony at ubuntu:~/auto/sel/scripts$ python -V
Python 2.7.1+

----------
components: Regular Expressions
messages: 139810
nosy: juan.gonzalez
priority: normal
severity: normal
status: open
title: Inconsistent Python find() behavior
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  5 00:03:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 22:03:10 +0000
Subject: [issue12493] subprocess: Popen.communicate() doesn't handle EINTR in
	some cases
In-Reply-To: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>
Message-ID: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

subprocess.Popen.communicate() doesn't catch EINTR error if it is called without timeout and if there is only one PIPE (stdout or stderr).

Attached patch fixes these cases. It may need a test.

I found this bug while working on test_signal, especially on the inter process signal tests.

----------
components: Library (Lib)
files: subprocess_communicate_eintr.patch
keywords: patch
messages: 139811
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess: Popen.communicate() doesn't handle EINTR in some cases
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22571/subprocess_communicate_eintr.patch

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

From report at bugs.python.org  Tue Jul  5 00:13:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 22:13:45 +0000
Subject: [issue12494] subprocess: check_output() doesn't close pipes on error
In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>
Message-ID: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

subprocess.check_output() doesn't close explicitly pipes if an error occurs. See for example issue #12493 for an example of an error on .communicate().

Attached patch uses a context manager to ensure that all pipes are always closed and that the status is read to avoid zombies.

Other subprocess functions should be fixed:
 - call() (will fix check_call)
 - getstatusoutput() (will fix getoutput): see patch attached to the issue #10197 to replace os.popen() by subprocess.Popen

----------
components: Library (Lib)
files: subprocess_check_output.patch
keywords: patch
messages: 139812
nosy: haypo
priority: normal
severity: normal
status: open
title: subprocess: check_output() doesn't close pipes on error
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22572/subprocess_check_output.patch

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

From report at bugs.python.org  Tue Jul  5 00:33:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 22:33:21 +0000
Subject: [issue12495] Rewrite InterProcessSignalTests
In-Reply-To: <1309818801.22.0.236460194103.issue12495@psf.upfronthosting.co.za>
Message-ID: <1309818801.22.0.236460194103.issue12495@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

InterProcessSignalTests uses 4 different signal handlers (SIGUSR1, SIGUSR2, SIGALRM, SIGHUP) and uses 2 methods to raise a signal (a subprocess executing "kill -SIG pid" or signal.alarm(1)). It uses signal.pause() and/or time.sleep(1) to wait the signal, or just nothing for SIGUSR2 (configured to be ignored).

The testcase tests too many unrelated things.

signal.alarm(1) is not an interprocess signal: it is a signal send to the process itself.

Why using two different signal handlers? A modifies a_called, B modifies b_called but raise also a Python exception. How is it related to interprocess signal handling?

Why checking that the handler A (SIGHUP) has not been called when the signal handler B (SIGUSR1) is called?

Why is the garbage collector disabled?

I propose to write a new simple testcase: install a signal handler raising a Python exception, send a signal using a child process, ensure that the signal has been received (wait for the exception). Pseudo-code:

--------
s = signal.SIGUSR1
def handler(signum, frame): 1/0
signal.signal(s, handler)
try:
  subprocess.call([sys.executable, '-c', '... kill(%s, %s)' % (os.getpid(), s))
  ... wait the signal ...
except ZeroDivisionError:
  pass
else:
  raise Exception("ZeroDivisionError not raised"
--------

The whole test has to be run in a subprocess.

The new test may pass on freebsd 6, it should be checked (see issue #12469).

----------
components: Tests
messages: 139813
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: Rewrite InterProcessSignalTests
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  5 00:34:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Jul 2011 22:34:40 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309818880.5.0.602912874629.issue12469@psf.upfronthosting.co.za>


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

> run test_main() ... in a subprocesses

I created a new issue for this task: issue #12495. I think that the testcase has to be rewritten.

----------

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

From report at bugs.python.org  Tue Jul  5 01:04:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Jul 2011 23:04:57 +0000
Subject: [issue12440] test_ssl.test_options() failure on Snow Leopard: can't
	clear options before OpenSSL 0.9.8m
In-Reply-To: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>
Message-ID: <1309820697.09.0.325565620811.issue12440@psf.upfronthosting.co.za>


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

Two problems: (1) on OS X builds, libssl is dynamically linked to _ssl.so so there is a potential disconnect when combining checking versions based on a compile time check (as in _ssl.c) with an execution time check of the actual loaded library (as in test_ssl.py) and (2) in point releases (like 10.6.x), Apple often deliberately does not update the include files for libraries that were released in a major release (like 10.6).  As of 10.6.8, the /usr/include/openssl headers are at 0.9.8l but /usr/lib/libssl0.9.8.dylib is at 0.9.8r.

That said, we will probably need to supply our own libssl for Python installers in the future as there are rumors that Apple has hinted it may no longer supply openssl in the future.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Tue Jul  5 01:15:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 23:15:36 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <E1QdsMZ-00037v-6r@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset aad86a719fc6 by Victor Stinner in branch 'default':
Issue #12469: test_signal checks wakeup signals order, except on freebsd6
http://hg.python.org/cpython/rev/aad86a719fc6

----------

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

From report at bugs.python.org  Tue Jul  5 01:34:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Jul 2011 23:34:36 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <E1Qdsew-00043F-Sm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f12b8548b4aa by Victor Stinner in branch 'default':
Issue #12469: fix signal order check of test_signal
http://hg.python.org/cpython/rev/f12b8548b4aa

----------

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

From report at bugs.python.org  Tue Jul  5 02:28:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Jul 2011 00:28:29 +0000
Subject: [issue12496] test_ssl test_connect_capath fails with "certificate
	verify failed"
In-Reply-To: <1309825709.83.0.777324872875.issue12496@psf.upfronthosting.co.za>
Message-ID: <1309825709.83.0.777324872875.issue12496@psf.upfronthosting.co.za>


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

======================================================================
ERROR: test_connect_capath (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/test/test_ssl.py", line 584, in test_connect_capath
    s.connect(("svn.python.org", 443))
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/ssl.py", line 471, in connect
    self._real_connect(addr, False)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/ssl.py", line 461, in _real_connect
    self.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/ssl.py", line 441, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:392: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

----------
assignee: ned.deily
components: Tests
messages: 139818
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl test_connect_capath fails with "certificate verify failed"
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul  5 02:54:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 00:54:07 +0000
Subject: [issue12496] test_ssl test_connect_capath fails with "certificate
	verify failed"
In-Reply-To: <1309825709.83.0.777324872875.issue12496@psf.upfronthosting.co.za>
Message-ID: <E1Qdttt-0008JO-Hn@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7731c900ddce by Ned Deily in branch '3.2':
Issue #12496:  Install test/capath directory to prevent test_connect_capath
http://hg.python.org/cpython/rev/7731c900ddce

New changeset 880c3e764ead by Ned Deily in branch 'default':
Issue #12496:  Install test/capath directory to prevent test_connect_capath
http://hg.python.org/cpython/rev/880c3e764ead

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Jul  5 02:57:25 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Jul 2011 00:57:25 +0000
Subject: [issue12496] test_ssl test_connect_capath fails with "certificate
	verify failed"
In-Reply-To: <1309825709.83.0.777324872875.issue12496@psf.upfronthosting.co.za>
Message-ID: <1309827445.34.0.107166497574.issue12496@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jul  5 03:54:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Jul 2011 01:54:16 +0000
Subject: [issue12497] test_codecmaps_* skipped - Could not retrieve *
In-Reply-To: <1309830856.17.0.0825089437233.issue12497@psf.upfronthosting.co.za>
Message-ID: <1309830856.17.0.0825089437233.issue12497@psf.upfronthosting.co.za>


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

[ 54/352] test_codecmaps_cn
	fetching http://source.icu-project.org/repos/icu/data/trunk/charset/data/xml/gb-18030-2000.xml ...
test_codecmaps_cn skipped -- Could not retrieve http://source.icu-project.org/repos/icu/data/trunk/charset/data/xml/gb-18030-2000.xml
[ 55/352] test_codecmaps_hk
	fetching http://people.freebsd.org/~perky/i18n/BIG5HKSCS-2004.TXT ...
test_codecmaps_hk skipped -- Could not retrieve http://people.freebsd.org/~perky/i18n/BIG5HKSCS-2004.TXT
[ 56/352] test_codecmaps_jp
	fetching http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT ...
test_codecmaps_jp skipped -- Could not retrieve http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT
[ 57/352] test_codecmaps_kr
	fetching http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP949.TXT ...
test_codecmaps_kr skipped -- Could not retrieve http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP949.TXT
[ 58/352] test_codecmaps_tw
	fetching http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT ...
test_codecmaps_tw skipped -- Could not retrieve http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT

----------
assignee: ned.deily
components: Tests
messages: 139820
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: test_codecmaps_* skipped - Could not retrieve *
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul  5 03:55:30 2011
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Xavier_Bourlet?=)
Date: Tue, 05 Jul 2011 01:55:30 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>


New submission from Fran?ois-Xavier Bourlet <bombela at gmail.com>:

Actually the class asyncore.dispatcher_with_send do not handle properly disconnection. When the endpoint shutdown his sending part of the socket, but keep the socket open in reading, the current implementation of dispatcher_with_send will close the socket without sending pending data.

Adding this method to the class fix the problem:

    def handle_close(self):
        if not self.writable():
            dispatcher.close()

Note also that this class try to initiate a send even if the socket is maybe not ready for writing:

Here's a simple fix:
    def send(self, data):
        if self.debug:
            self.log_info('sending %s' % repr(data))
        self.out_buffer = self.out_buffer + data
-       self.initiate_send()

Last but not last, the buffer size of each socket send are way to small (512, a third of an usual TCP frame). Here's the code with a bumped value:

    def initiate_send(self):
        num_sent = 0
-       num_sent = dispatcher.send(self, self.out_buffer[:512])
+       num_sent = dispatcher.send(self, self.out_buffer[:8192])
        self.out_buffer = self.out_buffer[num_sent:]

Thanks for reading,

----------
components: IO
messages: 139821
nosy: Fran?ois-Xavier.Bourlet
priority: normal
severity: normal
status: open
title: asyncore.dispatcher_with_send, disconnection problem + miss-conception
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  5 04:11:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 02:11:47 +0000
Subject: [issue12497] test_codecmaps_* skipped - Could not retrieve *
In-Reply-To: <1309830856.17.0.0825089437233.issue12497@psf.upfronthosting.co.za>
Message-ID: <E1Qdv73-0004LV-K4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 95301c58c5d2 by Ned Deily in branch '3.2':
Issue #12497: Install test/data to prevent failures of the various codecmaps
http://hg.python.org/cpython/rev/95301c58c5d2

New changeset 842147eb1b26 by Ned Deily in branch 'default':
Issue #12497: Install test/data to prevent failures of the various codecmaps
http://hg.python.org/cpython/rev/842147eb1b26

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Jul  5 04:12:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Jul 2011 02:12:46 +0000
Subject: [issue12497] test_codecmaps_* skipped - Could not retrieve *
In-Reply-To: <1309830856.17.0.0825089437233.issue12497@psf.upfronthosting.co.za>
Message-ID: <1309831966.82.0.70263119988.issue12497@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jul  5 04:20:34 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 05 Jul 2011 02:20:34 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309832434.55.0.425324431125.issue12492@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Python 2.7.2 (default, Jun 16 2011, 01:46:46) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "hola".find("q") > 0
False
>>> "hola".find("q") < 0
True

I don't see the problem. Please, send a complete testcase.

----------
nosy: +jcea

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

From report at bugs.python.org  Tue Jul  5 04:21:45 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 05 Jul 2011 02:21:45 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309832505.21.0.118547762244.issue12492@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Note, anyway, that your python is not a real release. where is it coming from?.

----------

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

From report at bugs.python.org  Tue Jul  5 04:40:06 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 05 Jul 2011 02:40:06 +0000
Subject: [issue12485] textwrap.wrap: add control for custom length and orphans
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1309833606.19.0.402560678237.issue12485@psf.upfronthosting.co.za>


Tyler Romeo <tylerromeo at gmail.com> added the comment:

Nah, they're both unrelated. I'll separate the changes and remake the patches. (I'll keep this entry for the beautification part.)

----------

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

From report at bugs.python.org  Tue Jul  5 04:43:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jul 2011 02:43:09 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309790216.55.0.139193640866.issue10181@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eSy6d6A6yA-r0AOgrup8n1mLyg6fr0QT9BXx6Hxq9v0g@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Tue, Jul 5, 2011 at 12:36 AM, Pauli Virtanen <report at bugs.python.org> wrote:
> Slicing memoryviews can invalidate the contiguity flags, and no-strides flags, so some checks are still probably needed in `memory_getbuf`.

That makes sense, so just as memoryview has its own shape and strides
data, it will also need its own flags data that *starts* as a copy of
that in the original buffer, but may be subsequently modified.

----------

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

From report at bugs.python.org  Tue Jul  5 04:53:24 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 05 Jul 2011 02:53:24 +0000
Subject: [issue12485] textwrap.wrap: add control for custom length and orphans
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1309834404.23.0.436551614153.issue12485@psf.upfronthosting.co.za>


Tyler Romeo <tylerromeo at gmail.com> added the comment:

OK, so here is the patch for just the new algorithm.

----------
Added file: http://bugs.python.org/file22573/textwrap.py-new-algorithm-2011-07-04_22-45-53_r71219+.diff

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

From report at bugs.python.org  Tue Jul  5 05:03:24 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 05 Jul 2011 03:03:24 +0000
Subject: [issue12499] textwrap.wrap: add control for fonts with different
	character widths
In-Reply-To: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>
Message-ID: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>


New submission from Tyler Romeo <tylerromeo at gmail.com>:

Originally from http://bugs.python.org/issue12485 but separated.

The textwrap modules uses len to determine the length of text, but in many (if not most) fonts, the width of a character differs depending on the letter, so it would be useful to have an option to pass a custom function that returns the width of a given string of text.

----------
components: Library (Lib)
files: textwrap.py-widthfunction-2011-07-04_22-57-49_r71219+.diff
keywords: patch
messages: 139828
nosy: parent5446
priority: normal
severity: normal
status: open
title: textwrap.wrap: add control for fonts with different character widths
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22574/textwrap.py-widthfunction-2011-07-04_22-57-49_r71219+.diff

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

From report at bugs.python.org  Tue Jul  5 05:04:36 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 05 Jul 2011 03:04:36 +0000
Subject: [issue12485] textwrap.wrap: add control for custom length and orphans
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1309835076.09.0.135200915437.issue12485@psf.upfronthosting.co.za>


Changes by Tyler Romeo <tylerromeo at gmail.com>:


Removed file: http://bugs.python.org/file22561/textwrap.py-improvement.diff

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

From report at bugs.python.org  Tue Jul  5 07:04:16 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 05 Jul 2011 05:04:16 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1309842256.18.0.990964426964.issue10883@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
resolution:  -> accepted
stage:  -> patch review

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

From report at bugs.python.org  Tue Jul  5 08:10:03 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Jul 2011 06:10:03 +0000
Subject: [issue12499] textwrap.wrap: add control for fonts with different
	character widths
In-Reply-To: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>
Message-ID: <1309846203.81.0.204226730056.issue12499@psf.upfronthosting.co.za>


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

About the patch: the function should not be passed to the constructor, it could be a regular method that can be overridden in subclasses.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Tue Jul  5 08:37:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Jul 2011 06:37:55 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309847875.84.0.488163400007.issue12492@psf.upfronthosting.co.za>


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

I suspect this is a problem where "url" is reassigned to an integer somewhere in code that isn't shown to us.

Please post the whole function and the whole traceback if you still think this is a valid bug.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Tue Jul  5 08:59:53 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 05 Jul 2011 06:59:53 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <E1Qdsew-00043F-Sm@dinsdale.python.org>
Message-ID: <CAH_1eM1Qa5nhxVa8fdnTvHB8eRyuD5xetWum_swpTs26Xx+i-w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> When signals are unblocked, pending signal ared delivered in the reverse order
> of their number (also on Linux, not only on FreeBSD 6).

I don't like this.
POSIX doesn't make any guarantee about signal delivery order, except
for real-time signals.
It might work on FreeBSD and Linux, but that's definitely not
documented, and might break with new kernel releases, or other
kernels.

----------

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

From report at bugs.python.org  Tue Jul  5 10:05:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 08:05:15 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <CAH_1eM1Qa5nhxVa8fdnTvHB8eRyuD5xetWum_swpTs26Xx+i-w@mail.gmail.com>
Message-ID: <1309853116.2491.2.camel@marge>


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

> > When signals are unblocked, pending signal ared delivered in the reverse order
> > of their number (also on Linux, not only on FreeBSD 6).
> 
> I don't like this.
> POSIX doesn't make any guarantee about signal delivery order, except
> for real-time signals.
> It might work on FreeBSD and Linux, but that's definitely not
> documented, and might break with new kernel releases, or other
> kernels.

It looks like it works like this on most OSes (Linux, Mac OS X, Solaris,
FreeBSD): I don't see any test_signal failure on 3.x buildbots. If we
have a failure, we can use set() again, but only for test_pending:
signal order should be reliable if signals are not blocked.

----------

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

From report at bugs.python.org  Tue Jul  5 10:22:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 08:22:59 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1309854179.48.0.193288816015.issue12149@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/issue12149>
_______________________________________

From report at bugs.python.org  Tue Jul  5 10:25:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 08:25:15 +0000
Subject: [issue12500] support.transient_internet(): catch also Windows socket
	errors
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

======================================================================
ERROR: test_non_blocking_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_ssl.py", line 518, in test_non_blocking_connect_ex
    s.do_handshake()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\ssl.py", line 442, in do_handshake
    self._sslobj.do_handshake()
socket.error: [Errno 10057] A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied

======================================================================
FAIL: test_connect_ex (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_ssl.py", line 495, in test_connect_ex
    self.assertEqual(0, s.connect_ex(("svn.python.org", 443)))
AssertionError: 0 != 10061

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4918/steps/test/logs/stdio

WSAECONNREFUSED (10061): "Connection refused."

WSAENOTCONN (10057): "Socket is not connected."

It is obvious that transient_internet() should catch WSAECONNREFUSED, but for WSAENOTCONN, I don't understand why it happens on a SSL handshake.

Attached patch catchs both errors. We may start with only WSAECONNREFUSED, and maybe add a specific code for test_ssl?

----------
components: Tests
files: transient_internet_windows.patch
keywords: patch
messages: 139833
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: support.transient_internet(): catch also Windows socket errors
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22575/transient_internet_windows.patch

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

From report at bugs.python.org  Tue Jul  5 10:32:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 05 Jul 2011 08:32:04 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1309854724.22.0.930168177033.issue12149@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

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

From report at bugs.python.org  Tue Jul  5 10:39:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Jul 2011 08:39:58 +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: <1309855198.93.0.94931141746.issue10181@psf.upfronthosting.co.za>


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

Nick, Pauli, thanks for all the comments. I'm busy implementing the easy changes; then it'll be easier to deal with the flags issues.


Pauli: 
 
Does numpy use the (undocumented) smalltable array in the Py_buffer
structure? We would like to drop it.

----------

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

From report at bugs.python.org  Tue Jul  5 11:13:42 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 05 Jul 2011 09:13:42 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1309842256.24.0.071868259293.issue10883@psf.upfronthosting.co.za>
Message-ID: <20110705091336.GA2978@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

With the patch applied, test_urllib2net fails at test_ftp test case
when a valid and invalid url are presented in sequence. I think test
needs a change or a further look is needed at the patch.

----------

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

From report at bugs.python.org  Tue Jul  5 11:28:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 09:28:36 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <E1Qe1vm-0001Od-KM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6abbc5f68e20 by Victor Stinner in branch '2.7':
Issue #9611, #9015: FileIO.read(), FileIO.readinto(), FileIO.write() and
http://hg.python.org/cpython/rev/6abbc5f68e20

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Jul  5 11:31:24 2011
From: report at bugs.python.org (Stephen White)
Date: Tue, 05 Jul 2011 09:31:24 +0000
Subject: [issue12431] urllib2.Request.get_full_url() broken in newer versions
	of Python
In-Reply-To: <1309268248.69.0.295956213219.issue12431@psf.upfronthosting.co.za>
Message-ID: <1309858284.0.0.0248812374457.issue12431@psf.upfronthosting.co.za>


Stephen White <stephen-python.org at randomstuff.org.uk> added the comment:

Just to confirm that it was a release, but 2.7.1 so not the current.  Doesn't appear to happen in Python 2.7 (as shipped with Fedora Core 14) or in Python 2.7.2.

C:\>\Python27\python.exe
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.Request("http://host/path#fragment").get_full_url()
'http://host/path'
>>>

Upgrading our affected Windows boxes to Python 2.7.2 seems to solve the problem.

We're happy for this bug to remain closed.

----------
nosy: +Stephen.White

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

From report at bugs.python.org  Tue Jul  5 11:38:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 09:38:43 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <E1Qe25a-0002aF-Fi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7acdf9f5eb31 by Victor Stinner in branch '3.2':
Issue #9611, #9015: FileIO.read() clamps the length to INT_MAX on Windows.
http://hg.python.org/cpython/rev/7acdf9f5eb31

New changeset e8646f120330 by Victor Stinner in branch 'default':
(merge 3.2) Issue #9611, #9015: FileIO.read() clamps the length to INT_MAX on Windows.
http://hg.python.org/cpython/rev/e8646f120330

----------

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

From report at bugs.python.org  Tue Jul  5 11:46:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 09:46:58 +0000
Subject: [issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1309859218.77.0.131337474487.issue9015@psf.upfronthosting.co.za>


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

This issue is a duplicate of #9611.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Tue Jul  5 11:49:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 09:49:53 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1309859393.1.0.920313487681.issue9611@psf.upfronthosting.co.za>


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

I backported fixes to 2.7, and also add a new fix to FileIO.read(). I don't see anything else to do on this issue, so I close it.

Note: read() and write() methods the file object in 2.7 are 64-bit safe on any OS. They use fread() and frwrite() which take a length in the size_t type, not in int type even on Windows.

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

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

From report at bugs.python.org  Tue Jul  5 11:51:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 09:51:54 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1309859514.47.0.540311780312.issue9611@psf.upfronthosting.co.za>


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

Issue #9015 has been marked as a duplicate of this issue.

----------

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

From report at bugs.python.org  Tue Jul  5 11:56:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 09:56:13 +0000
Subject: [issue12469] test_faulthandler failures on FreeBSD 6
In-Reply-To: <1309548496.09.0.185802597243.issue12469@psf.upfronthosting.co.za>
Message-ID: <1309859773.36.0.178669134425.issue12469@psf.upfronthosting.co.za>


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

I close this issue because test_signal pass on FreeBSD 6 buildbots (3.2 and 3.x). I will reopen it if test_faulthandler fails or if test_signal fails again, or maybe open new issues.

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

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

From report at bugs.python.org  Tue Jul  5 12:27:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 10:27:04 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309861624.43.0.0839242325324.issue8716@psf.upfronthosting.co.za>


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

> New changeset ea02eca122b5 by Ned Deily in branch '2.7':
> Issue #8716: Avoid crashes caused by Aqua Tk on OSX when attempting to run
> http://hg.python.org/cpython/rev/ea02eca122b5

> New changeset 06cb0d602468 by Ned Deily in branch '2.7':
> Issue #8716: Fix errors in the non-OS X path of the 27 backport.
> http://hg.python.org/cpython/rev/06cb0d602468

Build #200 (revision 6abbc5f68e20eb01094dbbcf486c2ba0e1e4fa77) of "AMD64 Snow Leopard 2 2.7" crashed:

test_ttk_guionly
make: *** [buildbottest] Segmentation fault

http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%202.7/builds/200/

runtktests.check_tk_availability() creates a Tkinter.Button() in a subprocess. It should maybe try to create a ttk.Button() for test_ttk_guionly instead of Tkinter.Button().

----------
status: pending -> open

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

From report at bugs.python.org  Tue Jul  5 12:47:43 2011
From: report at bugs.python.org (Florian Preinstorfer)
Date: Tue, 05 Jul 2011 10:47:43 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1309862863.24.0.628710464298.issue11468@psf.upfronthosting.co.za>


Florian Preinstorfer <nblock at archlinux.us> added the comment:

I tried to implement the improvements suggested by Ezio Melotti and updated the documentation accordingly.

----------
keywords: +patch
nosy: +notizblock
Added file: http://bugs.python.org/file22576/issue-11468.patch

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

From report at bugs.python.org  Tue Jul  5 12:47:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Jul 2011 10:47:50 +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: <1309862870.33.0.862498328254.issue10181@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file22577/718801740bde.diff

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

From report at bugs.python.org  Tue Jul  5 12:48:57 2011
From: report at bugs.python.org (Neil Muller)
Date: Tue, 05 Jul 2011 10:48:57 +0000
Subject: [issue11439] subversion keyword breakage
In-Reply-To: <1299597022.39.0.100246713924.issue11439@psf.upfronthosting.co.za>
Message-ID: <1309862937.93.0.136811191346.issue11439@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

SVN_Revision.diff replaces the remaining "$Revision$" keywords in 2.7 with the values from the last SVN checkout I have. This seems the correct minimal fix for the issues caused by code parsing the revision tag in Python 2. I've left the various other keywords untouched in 2.7 (mainly $Id$ tags) untouched, since they appear to be unused.

----------
keywords: +patch
Added file: http://bugs.python.org/file22578/SVN_Revision.diff

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

From report at bugs.python.org  Tue Jul  5 12:49:41 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Jul 2011 10:49:41 +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: <1309862981.8.0.603839233593.issue10181@psf.upfronthosting.co.za>


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

I've uploaded a revised version that addresses several suggestions. I think 
we have agreement on those now:

  - Officially ditch smalltable.

  - Comment static storage fields inside PyMemoryViewObject.

  - Improve refcounting in PyMemoryView_FromBuffer()/PyMemoryView_FromObject().

  - Increment mbuf refcount in memory_getbuf().

  - Create separate sections for managedbuffer and memoryview.


Still open:

  - Update documentation.

  - Should PyManagedBuffer be private to this file? Do we need mbuf_new()?

  - Add test to _testcapimodule.c. I wrote a small test for the problematic
    case in PyMemoryView_GetContiguous(), and it indeed returns an unaltered
    view. I suggest that we leave the NotImplementedError for now and handle
    that in a separate issue.

  - Flag handling.

----------

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

From report at bugs.python.org  Tue Jul  5 12:56:44 2011
From: report at bugs.python.org (Neil Muller)
Date: Tue, 05 Jul 2011 10:56:44 +0000
Subject: [issue11439] subversion keyword breakage
In-Reply-To: <1299597022.39.0.100246713924.issue11439@psf.upfronthosting.co.za>
Message-ID: <1309863404.22.0.43484594151.issue11439@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

This patch removes or replaces a number SVN keywords which aren't buried in comments.

I've removed '__revision__ = "$Id$"' cases - mainly present in distutils - as no-one appears to using these.

I've replaced values in tarfile.py, but they can probably be removed as well.

----------
Added file: http://bugs.python.org/file22579/cleanup_3.3svn_keywords.diff

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

From report at bugs.python.org  Tue Jul  5 13:02:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 11:02:45 +0000
Subject: [issue12494] subprocess: check_output() doesn't close pipes on error
In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>
Message-ID: <1309863765.68.0.0768928595323.issue12494@psf.upfronthosting.co.za>


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

subprocess_check_output-2.patch is a more complete patch: "fix" (?) call(), check_output() and getstatusoutput(). These functions kill the process if an exception occurs to not hang on wait() in Popen.__exit__().

Because of the kill, I don't know if the fix should be applied to 2.7 and 3.2. In case of an exception, is it better to keep the subprocess alive, or to kill it? If we keep it alive, the caller of the function cannot interact with the process, and we don't know exactly when it will finish.

By "exception", I mean unexpected exceptions: check_output() handles explicitly the TimeoutExpired exception.

----------
Added file: http://bugs.python.org/file22580/subprocess_check_output-2.patch

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

From report at bugs.python.org  Tue Jul  5 13:03:50 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Jul 2011 11:03:50 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309863830.01.0.115192465272.issue8716@psf.upfronthosting.co.za>


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

python2.7 has MacOS.WMAvailable().  When that function returns False the Tkinter tests should be disabled.

The function is not available in Python 3, but is easy enough to implement using ctypes.

----------

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

From report at bugs.python.org  Tue Jul  5 13:20:42 2011
From: report at bugs.python.org (=?utf-8?b?VG9tYcW+IMWgb2xj?=)
Date: Tue, 05 Jul 2011 11:20:42 +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: <1309864842.21.0.629203178239.issue6721@psf.upfronthosting.co.za>


Toma? ?olc <tomaz.solc at tablix.org> added the comment:

Except for multiprocessing, does anyone know of any other module in the standard library that uses fork() and threads at the same time? After some grepping through the source I couldn't find any other cases.

I'm still in favor of just deprecating using fork() on a multithreaded process (with appropriate warnings and documentation) and I'm prepared to work on a patch that would remove the need for helper threads in the multiprocessing module.

I gather that having atfork would be useful beyond attempting to solve the locking problem, so this doesn't mean I'm opposed to it. However debugging rare problems in multithreaded/multiprocess applications is such a frustrating task that I really don't like a solution that only works in the common case.

> In Python atfork() handlers will never run from signal handlers, and 
> if I understood correctly, Charles-Fran?ois described a way to 
> "re-initialize" a Python lock safely under that assumption.

Just to clarify: it's not that POSIX atfork() handlers run from signal handlers. It's that after a fork in a multithreaded process POSIX only guarantees calls to "safe" functions, which is the same set of functions as those that are safe to call from signal handlers. This fact does not change for Python's os.fork().

----------

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

From report at bugs.python.org  Tue Jul  5 13:23:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 11:23:39 +0000
Subject: [issue12500] support.transient_internet(): catch also Windows socket
	errors
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309865019.01.0.84221249525.issue12500@psf.upfronthosting.co.za>


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

You don't need to add WSAECONNREFUSED, it's already there as ECONNREFUSED:

>>> errno.ECONNREFUSED
10061
>>> errno.WSAECONNREFUSED
10061

As for (WSA)ENOTCONN, I don't want to add it before knowing what happens. It may signal a programming error.

----------

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

From report at bugs.python.org  Tue Jul  5 13:29:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 11:29:35 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309864842.21.0.629203178239.issue6721@psf.upfronthosting.co.za>
Message-ID: <1309865326.3683.3.camel@localhost.localdomain>


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

> Except for multiprocessing, does anyone know of any other module in
> the standard library that uses fork() and threads at the same time?
> After some grepping through the source I couldn't find any other
> cases.

It's quite common to launch a subprocess from a thread, so as to
communicate with the subprocess without blocking the main thread. I'm
not sure the stdlib itself does it, but the test suite does (when run in
parallel mode).

> I'm prepared to work on a patch that would remove the need for helper
> threads in the multiprocessing module.

Your contribution is welcome.

> Just to clarify: it's not that POSIX atfork() handlers run from signal
> handlers. It's that after a fork in a multithreaded process POSIX only
> guarantees calls to "safe" functions, which is the same set of
> functions as those that are safe to call from signal handlers.

For the record, I would consider POSIX totally broken from this point of
view. It seems most modern systems allow much more than that,
fortunately.

----------

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

From report at bugs.python.org  Tue Jul  5 13:35:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 11:35:50 +0000
Subject: [issue12501] callable(): remove the deprecation warning from Python
	2.7
In-Reply-To: <1309865750.34.0.541248470896.issue12501@psf.upfronthosting.co.za>
Message-ID: <1309865750.34.0.541248470896.issue12501@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python 2.7 emits a DeprecationWarning warning if callable() is called and python has the -3 option. callable() was removed in Python 3.0, but it was also added again in Python 3.2 (issue #10518).

$ ./python -bb -3 -Werror 
Python 2.7.2+ (2.7:7bfedb159e82, Jul  5 2011, 13:23:38) 
>>> callable(int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
DeprecationWarning: callable() not supported in 3.x; use isinstance(x, collections.Callable)

I propose to drop the warning from Python 2.7. Use the six module if you would like to support Python 3.1, or use directly the following workaround in your code:

def callable(obj):
   return any("__call__" in klass.__dict__ for klass in type(obj).__mro__)

Attached patch removes the warning.

By the way, the six should be updated for Python 3.2: callable is a builtin again ;-)

----------
files: callable_warning.patch
keywords: patch
messages: 139853
nosy: benjamin.peterson, haypo, pitrou
priority: normal
severity: normal
status: open
title: callable(): remove the deprecation warning from Python 2.7
versions: Python 2.7
Added file: http://bugs.python.org/file22581/callable_warning.patch

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

From report at bugs.python.org  Tue Jul  5 13:38:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 11:38:49 +0000
Subject: [issue12500] support.transient_internet(): catch also Windows socket
	errors
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309865929.27.0.625663259552.issue12500@psf.upfronthosting.co.za>


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

> You don't need to add WSAECONNREFUSED,
> it's already there as ECONNREFUSED

Oh ok. Here is a patch for test_ssl.test_connect_ex() ignoring ECONNREFUSED error.

----------
Added file: http://bugs.python.org/file22582/test_ssl.patch

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

From report at bugs.python.org  Tue Jul  5 13:41:23 2011
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 05 Jul 2011 11:41:23 +0000
Subject: [issue12489] email.errors.HeaderParseError if base64url is used
In-Reply-To: <1309790300.23.0.111625308862.issue12489@psf.upfronthosting.co.za>
Message-ID: <1309866083.78.0.940073191919.issue12489@psf.upfronthosting.co.za>


Thomas Guettler <guettli at thomas-guettler.de> added the comment:

I received this email. Here is the creator:

X-Mailer: CommuniGate Pro MAPI Connector 1.52.53.10/1.53.10.1

----------

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

From report at bugs.python.org  Tue Jul  5 13:44:54 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Jul 2011 11:44:54 +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: <1309866294.14.0.527481806817.issue10181@psf.upfronthosting.co.za>


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

I'm slightly confused about the implication chain in the flags. PyBUF_STRIDES 
seem to allow for discontiguous arrays, yet STRIDES -> ND -> C_CONTIGUOUS.



                                 PyBUF_FULL[_RO]
                                       |
    PyBUF_INDIRECT -------------- PyBUF_FORMAT ----------[PyBUF_WRITABLE]         
          |
    PyBUF_STRIDES (This would be used when the consumer can handle strided, discontiguous arrays ...)
          |
      PyBUF_ND  <-> PyBUF_CONTIG (why?) 
          |
  PyBUF_C_CONTIGUOUS (... but the implication chain leads us to a contiguous buffer)

----------

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

From report at bugs.python.org  Tue Jul  5 13:45:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 11:45:15 +0000
Subject: [issue12500] support.transient_internet(): catch also Windows socket
	errors
In-Reply-To: <1309865929.27.0.625663259552.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309866267.3683.4.camel@localhost.localdomain>


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

> Oh ok. Here is a patch for test_ssl.test_connect_ex() ignoring ECONNREFUSED error.

IMO you also want to test for the other errnos in transient_internet.
Also, it should skip the test if the connection is refused.

----------

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

From report at bugs.python.org  Tue Jul  5 13:47:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 05 Jul 2011 11:47:12 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309864842.21.0.629203178239.issue6721@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2SKXifR_uFXCuTW2ptAtbircuDA+R36R973bvMYJOf3g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Except for multiprocessing, does anyone know of any other module in the standard library that uses fork() and threads at the
> same time? After some grepping through the source I couldn't find any other cases.

The same problem arises in case of user-created threads, this problem
is not specific to the multiprocessing.

> Just to clarify: it's not that POSIX atfork() handlers run from signal handlers. It's that after a fork in a multithreaded process POSIX only guarantees calls to "safe" functions, which is the same set of functions as those that are safe to call from signal handlers. This fact does not change for Python's os.fork().
>

I think Nir knows perfectly that, he was just referring to a
limitation of pthread_atfork:
- fork() is async-safe, and thus can be called from a signal handler
- but if pthread_atfork handlers are installed, then fork() can become
non async-safe, if the handlers are not async-safe (and it's the case
when you're dealing with POSIX mutexes for example)
But since Python's user-defined signal handlers are actually called
synchronously (and don't run on behalf of the signal handler), there's
no risk of fork() being called from a signal handler.

> I'm still in favor of just deprecating using fork() on a multithreaded process (with appropriate warnings and documentation)

We can't do that, it would break existing code.
Furthermore, some libraries use threads behind the scene.

> I'm prepared to work on a patch that would remove the need for helper threads in the multiprocessing module.

What do you mean by helper threads?

----------

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

From report at bugs.python.org  Tue Jul  5 13:49:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 11:49:04 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309866294.14.0.527481806817.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309866496.3683.5.camel@localhost.localdomain>


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

> I'm slightly confused about the implication chain in the flags. PyBUF_STRIDES 
> seem to allow for discontiguous arrays, yet STRIDES -> ND -> C_CONTIGUOUS.

To be honest I have never understood anything about these flags, and I
doubt anyone without a numpy background would.

----------

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

From report at bugs.python.org  Tue Jul  5 14:08:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 12:08:18 +0000
Subject: [issue12493] subprocess: Popen.communicate() doesn't handle EINTR in
	some cases
In-Reply-To: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>
Message-ID: <E1Qe4QL-0006eU-CV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dcfacc2d93b4 by Victor Stinner in branch '3.2':
Issue #12493: subprocess: communicate() handles EINTR
http://hg.python.org/cpython/rev/dcfacc2d93b4

New changeset 42e23db3ddfc by Victor Stinner in branch 'default':
(merge 3.2) Issue #12493: subprocess: communicate() handles EINTR
http://hg.python.org/cpython/rev/42e23db3ddfc

New changeset 6a28ccde2f1b by Victor Stinner in branch '2.7':
Issue #12493: subprocess: communicate() handles EINTR
http://hg.python.org/cpython/rev/6a28ccde2f1b

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Jul  5 14:09:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 12:09:30 +0000
Subject: [issue12493] subprocess: Popen.communicate() doesn't handle EINTR in
	some cases
In-Reply-To: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>
Message-ID: <1309867770.63.0.63699753718.issue12493@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jul  5 14:11:52 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Tue, 05 Jul 2011 12:11:52 +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: <1309867912.23.0.45707467607.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

The flags don't seem to be meant to describe the properties of the buffer, only what the exporter is required to fill in. STRIDES does not imply necessarily discontinuous, only that the `strides` field is present. The C_/F_/ANY_CONTIGUOUS flags imply that the memory layout of an n-dim array is C/Fortran/either contiguous. Why these flags imply STRIDES is probably to make the result unambiguous, and because typically when dealing with n-d arrays you usually need to know the strides anyway. `NULL` `strides` implies C-contiguous, so the CONTIG flag does not imply STRIDES (no idea why it's different from PyBUF_C_CONTIGUOUS).

----------

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

From report at bugs.python.org  Tue Jul  5 14:19:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 12:19:40 +0000
Subject: [issue12500] support.transient_internet(): catch also Windows socket
	errors
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309868380.63.0.944499695757.issue12500@psf.upfronthosting.co.za>


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

Updated patch: add support.transient_errors tuple.

----------
Added file: http://bugs.python.org/file22583/test_ssl-2.patch

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

From report at bugs.python.org  Tue Jul  5 14:19:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 12:19:44 +0000
Subject: [issue12500] support.transient_internet(): catch also Windows socket
	errors
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309868384.02.0.612941225104.issue12500@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file22575/transient_internet_windows.patch

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

From report at bugs.python.org  Tue Jul  5 14:19:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 12:19:46 +0000
Subject: [issue12500] support.transient_internet(): catch also Windows socket
	errors
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309868386.16.0.256825998628.issue12500@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file22582/test_ssl.patch

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

From report at bugs.python.org  Tue Jul  5 14:20:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 12:20:05 +0000
Subject: [issue12500] Skip test_ssl.test_connect_ex() on connection error
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1309868405.25.0.83689489508.issue12500@psf.upfronthosting.co.za>


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


----------
title: support.transient_internet(): catch also Windows socket errors -> Skip test_ssl.test_connect_ex() on connection error

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

From report at bugs.python.org  Tue Jul  5 14:21:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 12:21:53 +0000
Subject: [issue12426] packaging.tests.test_command_install_dist.InstallTestCase
	failure
In-Reply-To: <1309251003.31.0.392399705206.issue12426@psf.upfronthosting.co.za>
Message-ID: <1309868513.93.0.402822277528.issue12426@psf.upfronthosting.co.za>


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

I didn't see this failure recently. Because packaging module (and tests) changed after the failure, I suppose that the bug is already fixed.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Jul  5 14:22:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 12:22:26 +0000
Subject: [issue12364] Deadlock in test_concurrent_futures
In-Reply-To: <1308504315.81.0.454658658034.issue12364@psf.upfronthosting.co.za>
Message-ID: <1309868546.19.0.438050920627.issue12364@psf.upfronthosting.co.za>


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


----------
title: Timeout (1 hour) in test_concurrent_futures.tearDown() on sparc solaris10 gcc 3.x -> Deadlock in test_concurrent_futures

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

From report at bugs.python.org  Tue Jul  5 14:32:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 12:32:02 +0000
Subject: [issue12451] open: avoid the locale encoding when possible
In-Reply-To: <1309436451.46.0.759652312058.issue12451@psf.upfronthosting.co.za>
Message-ID: <E1Qe4nC-0000Ls-WF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8b62f5d722f4 by Victor Stinner in branch '3.2':
Issue #12451: pydoc: html_getfile() now uses tokenize.open() to support Python
http://hg.python.org/cpython/rev/8b62f5d722f4

New changeset 2fbfb7ea362f by Victor Stinner in branch 'default':
(merge 3.2) Issue #12451: pydoc: html_getfile() now uses tokenize.open() to
http://hg.python.org/cpython/rev/2fbfb7ea362f

----------

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

From report at bugs.python.org  Tue Jul  5 14:37:41 2011
From: report at bugs.python.org (abdeljalil chehaibou)
Date: Tue, 05 Jul 2011 12:37:41 +0000
Subject: [issue8695] Issue while installing Python 2.6.5 in IBM AIX 6.1
In-Reply-To: <1273661486.25.0.2216975723.issue8695@psf.upfronthosting.co.za>
Message-ID: <1309869461.92.0.741269048628.issue8695@psf.upfronthosting.co.za>


Changes by abdeljalil chehaibou <abdeljalil.chehaibou at gmail.com>:


----------
nosy: +abdeljalil.chehaibou

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

From report at bugs.python.org  Tue Jul  5 14:47:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jul 2011 12:47:14 +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: <1309870034.21.0.937094452819.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It took me a bit of thinking, but I figured out why the "contiguous" flags imply STRIDES. A quick recap of all the flags:

WRITABLE -> error if can't support write access

FORMAT -> request format info in Py_buffer struct. Should never error, but report unsigned bytes if not requested

ND -> requests shape info in Py_buffer struct. Report 1 dimensional if not requested. Error if data is not C contiguous (as STRIDES is required to handle any non-C contiguous cases).

STRIDES -> requests shape and stride info. Error if correct buffer access requires stride support and this flag is not passed.

C_CONTIGUOUS/F_CONTIGUOUS/ANY_CONTIGUOUS -> variants that also request shape and stride info but are limited to handling C contiguous memory, Fortran contiguous memory or either.

INDIRECT -> requests shape and suboffset info. Error if correct buffer access requires suboffset support and this flag is not passed.

So, to address the specific confusion, the basic "STRIDES" request just says "give me the strides info" and I can deal with whatever you give me. The "CONTIGUOUS" variants say "give me the strides info, but I can only cope with certain layouts, so error if you can't provide them". "ND" is a way to say "I can copy with multiple dimensions, but only the C version without using strides info"

Suppose we have a 3x4 array of unsigned bytes (i.e. 12 bytes of data). In C format, the strides info would be [4, 1] (buf[0][0] and buf[0][1] are adjacent in memory, while buf[0][0] and buf[1][0] are 4 bytes apart). In FORTRAN format that layout is different, so the strides info would be [1, 3] (and now buf[0][0] and buf[1][0] are adjacent while buf[0][0] and buf[0][1] are 3 bytes apart).

The difference between ND and C_CONTIGUOUS is that the latter asks for both the shape and strides fields in the Py_buffer object to be populated while the former only requests shape information.

----------

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

From report at bugs.python.org  Tue Jul  5 14:49:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jul 2011 12:49:17 +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: <1309870157.87.0.172582007732.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

At least, that's the explanation based on the PEP - not sure where "CONTIG" as an alias for ND (N-dimensional) comes from. But then, smalltable was an undocumented novelty, too :)

----------

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

From report at bugs.python.org  Tue Jul  5 14:51:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 12:51:05 +0000
Subject: [issue12493] subprocess: Popen.communicate() doesn't handle EINTR in
	some cases
In-Reply-To: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>
Message-ID: <E1Qe55j-0001zo-T4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 807921ba241d by Victor Stinner in branch '3.2':
Issue #12493: skip test_communicate_eintr() if signal.SIGALRM is missing
http://hg.python.org/cpython/rev/807921ba241d

New changeset 4928cf093a11 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12493: skip test_communicate_eintr() if signal.SIGALRM is missing
http://hg.python.org/cpython/rev/4928cf093a11

New changeset 8a4c9c154b5d by Victor Stinner in branch '2.7':
Issue #12493: skip test_communicate_eintr() if signal.SIGALRM is missing
http://hg.python.org/cpython/rev/8a4c9c154b5d

----------

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

From report at bugs.python.org  Tue Jul  5 14:59:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jul 2011 12:59:02 +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: <1309870742.28.0.515124876634.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To address the "should PyManagedBuffer be public?" question: yes, I think so.

Given the amount of grief the raw PEP 3118 API has caused the memoryview implementation, I expect the easier lifecycle management provided by the PyObject based API may also help 3rd parties.

----------

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

From report at bugs.python.org  Tue Jul  5 15:04:43 2011
From: report at bugs.python.org (=?utf-8?b?VG9tYcW+IMWgb2xj?=)
Date: Tue, 05 Jul 2011 13:04:43 +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: <1309871083.71.0.146155019353.issue6721@psf.upfronthosting.co.za>


Toma? ?olc <tomaz.solc at tablix.org> added the comment:

> We can't do that, it would break existing code.

I would argue that such code is already broken.

> What do you mean by helper threads?

multiprocessing uses threads behind the scenes to handle queue traffic and such for individual forked processes. It's something I also wasn't aware of until Antoine pointed it out. It also has its own implementation of atfork hooks in an attempt to handle the locking issue.

----------

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

From report at bugs.python.org  Tue Jul  5 15:13:28 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jul 2011 13:13:28 +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: <1309871608.21.0.404387206096.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Regarding the Reitveld cc field: I tend not to add anyone to that and instead post comments to the tracker item to say that I've finished a review in Reitveld. If people want to see details they can go look at the review itself (or remove themselves from the bug nosy list if they have genuinely lost interest).

----------

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

From report at bugs.python.org  Tue Jul  5 15:42:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 13:42:08 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309871608.21.0.404387206096.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309873280.3683.11.camel@localhost.localdomain>


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

> Regarding the Reitveld cc field: I tend not to add anyone to that and
> instead post comments to the tracker item to say that I've finished a
> review in Reitveld. If people want to see details they can go look at
> the review itself (or remove themselves from the bug nosy list if they
> have genuinely lost interest).

Be aware the Rietveld integration is buggy: for example, I got no
notification of the current reviews. So it's better to post a message
mentioning the review anyway.

----------

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

From report at bugs.python.org  Tue Jul  5 16:02:55 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jul 2011 14:02: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: <1309874575.7.0.60252630482.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I don't think that's a bug, it's a missing feature in the integration (there's a request on the metatracker to add automatic notifications of new reviews on the bug itself).

I did mention the review above but it would have been easy to miss amongst the other comments.

----------

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

From report at bugs.python.org  Tue Jul  5 16:09:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 14:09:25 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309874575.7.0.60252630482.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309874917.3683.12.camel@localhost.localdomain>


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

> I don't think that's a bug, it's a missing feature in the integration
> (there's a request on the metatracker to add automatic notifications
> of new reviews on the bug itself).

It is a bug, actually. People on the nosy list are also on the Rietveld
cc list, but in the wrong form. See
http://psf.upfronthosting.co.za/roundup/meta/issue382

----------

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

From report at bugs.python.org  Tue Jul  5 16:09:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 14:09:46 +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: <1309874986.66.0.643609374168.issue10181@psf.upfronthosting.co.za>


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

(and so, for the record, I've added my own small review :))

----------

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

From report at bugs.python.org  Tue Jul  5 16:29:53 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Tue, 05 Jul 2011 14:29:53 +0000
Subject: [issue10608] Add a section to Windows FAQ explaining os.symlink
In-Reply-To: <1291315333.59.0.493313738075.issue10608@psf.upfronthosting.co.za>
Message-ID: <1309876193.24.0.826651301554.issue10608@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

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

From report at bugs.python.org  Tue Jul  5 16:37:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Jul 2011 14:37:02 +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: <1309876622.69.0.995707608745.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Moving this discussion out of the review comments:

Antoine is wanting to make release() nondeterministic by having the underlying buffer only released when all views using it either have release() called or are no longer referenced.

I contend that release() needs to mean "release the underlying memory *right now*" or it is completely pointless. The "I don't want to care about lifecycle issues" approach is already handled quite adequately by the ordinary refcounting semantics.

If ensuring that all references have been eliminated before release() is called is too much work for a user then the answer is simple: don't call release() and let the refcounting do the work.

----------

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

From report at bugs.python.org  Tue Jul  5 16:47:38 2011
From: report at bugs.python.org (Hans Bering)
Date: Tue, 05 Jul 2011 14:47:38 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1309877258.94.0.783794412568.issue10647@psf.upfronthosting.co.za>


Hans Bering <hans.bering at arcor.de> added the comment:

I'm sorry, but it seems the issue described in my previous edit (msg139566) is perhaps not related to the original Scrollbar problem. I had thought they were because of the superficial resemblance (i.e., crashes due to locale-dependent float handling for integer arguments), but I cannot reproduce the Scollbar problem.

Sorry for any inconvenience; is it possible to delete my entries? I would then submit them as an independent issue.

----------

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

From report at bugs.python.org  Tue Jul  5 16:55:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 14:55:52 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309876622.69.0.995707608745.issue10181@psf.upfronthosting.co.za>
Message-ID: <1309877703.3683.29.camel@localhost.localdomain>


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

> Antoine is wanting to make release() nondeterministic by having the
> underlying buffer only released when all views using it either have
> release() called or are no longer referenced.

That's not "nondeterministic" if everyone calls release(). Less so than
garbage collection anyway.

> I contend that release() needs to mean "release the underlying memory
> *right now*" or it is completely pointless. The "I don't want to care
> about lifecycle issues" approach is already handled quite adequately
> by the ordinary refcounting semantics.

Well, if you assume refcounting and no reference cycles, then release()
is AFAICT already useless. See issue9757 for the argument we had with
Guido ;)

My issue is that until now sliced memoryviews are independent objects
and are not affected by the releasing of the original memoryview. With
this patch, they are, and that's why I'm advocating for a subtler
approach (which would really mirror the current slicing semantics, and
wouldn't break compatibility ;)).

release() is supposed to mean "you can dispose of this memoryview", not
"you can dispose of any underlying memory area, even if there's some
sharing that I as an user don't know anything about" (*). By making
release() affect "related" memoryviews we are exposing an internal
implementation detail (the PyManagedBuffer sharing) as part of the API.

(*) for something similar, if you close() a file-like object obtained
through socket.makefile(), it doesn't close the underlying fd until all
other file-like objects are closed too

----------

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

From report at bugs.python.org  Tue Jul  5 17:11:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:11:26 +0000
Subject: [issue2506] Line tracing of continue after always-taken if is
	incorrect
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1309878686.64.0.812389004328.issue2506@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/issue2506>
_______________________________________

From report at bugs.python.org  Tue Jul  5 17:33:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 05 Jul 2011 15:33:19 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309877703.3683.29.camel@localhost.localdomain>
Message-ID: <20110705153112.GA22571@sleipnir.bytereef.org>


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

Antoine Pitrou <report at bugs.python.org> wrote:
> My issue is that until now sliced memoryviews are independent objects
> and are not affected by the releasing of the original memoryview. With
> this patch, they are, and that's why I'm advocating for a subtler
> approach (which would really mirror the current slicing semantics, and
> wouldn't break compatibility ;)).

I wrote a comment on rietveld (which failed to get mailed again). My plan
is to make the sliced views more independent by copying shape, strides,
and suboffsets unconditionally on construction.

Then it should always be possible to delete views independently.

With respect to releasing, the views are of course still dependent.

> release() is supposed to mean "you can dispose of this memoryview", not
> "you can dispose of any underlying memory area, even if there's some
> sharing that I as an user don't know anything about" (*). By making
> release() affect "related" memoryviews we are exposing an internal
> implementation detail (the PyManagedBuffer sharing) as part of the API.

I thought the rationale for the release() method was to allow sequences like:

b = bytearray()
m1 = memoryview(b)
m1.release() -> must call releasebuffer instantly.
b.resize(10) -> this might fail otherwise if the garbage collection is too slow.

So I think releasebuffer must be called on the original base object,
and only the ManagedBuffer can do that.

----------

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

From report at bugs.python.org  Tue Jul  5 17:39:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:39:24 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1309880364.28.0.0279512869528.issue12043@psf.upfronthosting.co.za>


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

I will commit the rest of the patch.

----------
assignee: docs at python -> eric.araujo
priority: low -> high

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

From report at bugs.python.org  Tue Jul  5 17:42:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:42:21 +0000
Subject: [issue12485] textwrap.wrap: new argument for more pleasing output
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1309880541.08.0.0485984329124.issue12485@psf.upfronthosting.co.za>


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

xrange does not exist in Python 3, it?s called range.  You should have seen yesterday that I changed the versions: as a new feature, this cannot go into stable releases, only into the next one.

I?m adding Georg to nosy per http://docs.python.org/devguide/experts

----------
nosy: +georg.brandl
title: textwrap.wrap: add control for custom length and orphans -> textwrap.wrap: new argument for more pleasing output

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

From report at bugs.python.org  Tue Jul  5 17:44:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:44:30 +0000
Subject: [issue12499] textwrap.wrap: add control for fonts with different
	character widths
In-Reply-To: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>
Message-ID: <1309880670.19.0.236973682785.issue12499@psf.upfronthosting.co.za>


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

Amaury, do you think it?s more common to subclass TextWrapper than just instantiate it?  I find the proposed API (an argument to __init__) very intuitive.

----------
keywords: +needs review
nosy: +eric.araujo, georg.brandl
stage:  -> patch review

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

From report at bugs.python.org  Tue Jul  5 17:45:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:45:59 +0000
Subject: [issue12501] callable(): remove/amend the deprecation warning in
	Python 2.7
In-Reply-To: <1309865750.34.0.541248470896.issue12501@psf.upfronthosting.co.za>
Message-ID: <1309880759.11.0.469453261837.issue12501@psf.upfronthosting.co.za>


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

What about this change instead:

-    if (PyErr_WarnPy3k("callable() not supported in 3.x; "
+    if (PyErr_WarnPy3k("callable() not supported in 3.1; "

----------
nosy: +eric.araujo
title: callable(): remove the deprecation warning from Python 2.7 -> callable(): remove/amend the deprecation warning in Python 2.7

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

From report at bugs.python.org  Tue Jul  5 17:46:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 15:46:41 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <20110705153112.GA22571@sleipnir.bytereef.org>
Message-ID: <1309880753.3683.36.camel@localhost.localdomain>


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

> I thought the rationale for the release() method was to allow sequences like:
> 
> b = bytearray()
> m1 = memoryview(b)
> m1.release() -> must call releasebuffer instantly.
> b.resize(10) -> this might fail otherwise if the garbage collection is too slow.

Well, that would still work with my proposal.
Now consider:

def some_library_function(byteslike):
    with memoryview(byteslike) as m2:
        # do something with m2

with memoryview(some_object) as m1:
    some_library_function(m1)
    ...
    print(m1[0])

That m1 becomes unusable after m2 is released in the library function is
completely counter-intuitive, and will make memoryviews a pain to use in
real life.

----------

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

From report at bugs.python.org  Tue Jul  5 17:55:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:55:29 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1309881329.59.0.872769994183.issue7231@psf.upfronthosting.co.za>


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

Duplicate of #9093 (or is it the reverse?)

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

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

From report at bugs.python.org  Tue Jul  5 17:55:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:55:36 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1309881336.51.0.820520443335.issue7231@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg139884

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

From report at bugs.python.org  Tue Jul  5 17:55:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 15:55:54 +0000
Subject: [issue7231] Windows installer does not add \Scripts folder to the path
In-Reply-To: <1256749152.57.0.801313448944.issue7231@psf.upfronthosting.co.za>
Message-ID: <1309881354.04.0.423747728512.issue7231@psf.upfronthosting.co.za>


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

Duplicate of #3561 (or maybe the reverse)

----------

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

From report at bugs.python.org  Tue Jul  5 18:02:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 16:02:49 +0000
Subject: [issue11123] problem with packaged dependency extracter script, pdeps
In-Reply-To: <1296859283.38.0.970778705728.issue11123@psf.upfronthosting.co.za>
Message-ID: <1309881769.07.0.743573418814.issue11123@psf.upfronthosting.co.za>


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

Looks good.  I suggest you test again and commit.

----------
nosy: +eric.araujo
stage:  -> patch review
type: crash -> behavior
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Tue Jul  5 18:03:48 2011
From: report at bugs.python.org (Juan Gonzalez)
Date: Tue, 05 Jul 2011 16:03:48 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309881828.01.0.485230663623.issue12492@psf.upfronthosting.co.za>


Juan Gonzalez <juan.gonzalez at ti.com> added the comment:

Today I tried to use parse() instead of find() and I found out the following response:


tony at ubuntu:~/auto/sel/scripts$ python wtfibmdom
Traceback (most recent call last):
  File "wtfibmdom", line 22, in <module>
    if url.parse(str) > 0:
AttributeError: 'str' object has no attribute 'parse'
tony at ubuntu:~/auto/sel/scripts$ python wtfibmdom
Title: j3-dcsled-prd-validation passed Fri, 01 Jul 2011 14:03:59 -0500
Description: Build passed
Traceback (most recent call last):
  File "wtfibmdom", line 22, in <module>
    if url.find(str) > 0:
AttributeError: 'int' object has no attribute 'find'


I think this behavior is inconsistent since the compiler is treating the url variable as int and string at the same time.

----------
status: pending -> open

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

From report at bugs.python.org  Tue Jul  5 18:06:25 2011
From: report at bugs.python.org (Juan Gonzalez)
Date: Tue, 05 Jul 2011 16:06:25 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309881985.27.0.794028777652.issue12492@psf.upfronthosting.co.za>


Juan Gonzalez <juan.gonzalez at ti.com> added the comment:

Hi Georg,

This is the python code listing:

from RSS import ns, CollectionChannel, TrackingChannel

#Create a tracking channel, which is a data structure that
#Indexes RSS data by item URL
tc = TrackingChannel()
str = 'j3-nspire-prd-validation'
index = 0
#Returns the RSSParser instance used, which can usually be ignored
#tc.parse("http://www.python.org/channews.rdf")
tc.parse("http://pdt-california.eps.ti.com:8080/dashboard/rss.xml")   

RSS10_TITLE = (ns.rss10, 'title')
RSS10_DESC = (ns.rss10, 'description')

#You can also use tc.keys()
items = tc.listItems()
for item in items:
    #Each item is a (url, order_index) tuple
    url = item[index]
    #print "RSS Item:", 
    #str.find(str, beg=0 end=len(string))
    if url.find(str) > 0:
         print "RSS Item:", url
	 break; 
    #Get all the data for the item as a Python dictionary
    index = index + 1
    item_data = tc.getItem(item)
    print "Title:", item_data.get(RSS10_TITLE, "(none)")
    print "Description:", item_data.get(RSS10_DESC, "(none)")

----------

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

From report at bugs.python.org  Tue Jul  5 18:07:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 16:07:09 +0000
Subject: [issue11394] Tools/demo, etc. are not installed
In-Reply-To: <1299217020.84.0.644136523007.issue11394@psf.upfronthosting.co.za>
Message-ID: <1309882029.88.0.537381862903.issue11394@psf.upfronthosting.co.za>


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

> Explicit request for inclusion? What kind of bureaucracy are you up to?

This probably means: bug reports.

The Tools directory may or may not be included in UNIX tarballs, Mac OS X installers or Windows installers.  It is not documented anywhere that they should be, so I think this report is invalid.  The primary users of Tools are developers and contributors, not Python users in general; the part of Tools/demo that survived the 3.2 Demo Purge is not very useful, and could be moved to the docs or the wiki IMHO.

----------
components:  -Windows
nosy: +eric.araujo
title: No Tools/demo, etc, on Windows -> Tools/demo, etc. are not installed

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

From report at bugs.python.org  Tue Jul  5 18:08:06 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Jul 2011 16:08:06 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309882086.28.0.832369533311.issue12492@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Can you post some example code or a test case?

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Tue Jul  5 18:10:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 16:10:35 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1309882235.68.0.372137339524.issue6931@psf.upfronthosting.co.za>


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

The patch by Filip does not add new features, so I?m adjusting versions.

I cannot review the patch only by reading it, but if someone gives me a timeit command I can post a benchmark for my Debian machine.

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jul  5 18:14:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 16:14:32 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1309882472.95.0.0711096517611.issue10318@psf.upfronthosting.co.za>


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

This 3.2 patch updates UNIX rights and shebangs in Tools/scripts.

I also edited mailerdaemon, which used a string exception.

----------
versions:  -Python 3.1
Added file: http://bugs.python.org/file22584/tools-scripts.diff

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

From report at bugs.python.org  Tue Jul  5 18:16:42 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 05 Jul 2011 16:16:42 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309882602.68.0.409665325759.issue12492@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Put the failing code inside a "try", and wrote in the "except": "print repr(url)". I am pretty sure your "url" can be, actually, a number.

Or print "url" just before the 'faulty' line. I guess you will be surprised.

----------

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

From report at bugs.python.org  Tue Jul  5 18:17:25 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 05 Jul 2011 16:17:25 +0000
Subject: [issue12499] textwrap.wrap: add control for fonts with different
	character widths
In-Reply-To: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>
Message-ID: <1309882645.44.0.0784512666122.issue12499@psf.upfronthosting.co.za>


Tyler Romeo <tylerromeo at gmail.com> added the comment:

Normally I would have just added it as a function to be overloaded, but because of the nature of the textwrap.wrap function (all kwargs are passed to the TextWrapper constructor) I thought it made a lot more sense to keep it as an argument to __init__.

----------

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

From report at bugs.python.org  Tue Jul  5 18:20:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Jul 2011 16:20:24 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <1309882824.26.0.368634524502.issue9860@psf.upfronthosting.co.za>


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

I am working on a patch to make patchcheck use os.path.join(sysconfig.get_config_var('srcdir'), etc.) to look for the .hg dir and open files (to do its checks) with the right paths.

----------

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

From report at bugs.python.org  Tue Jul  5 18:24:47 2011
From: report at bugs.python.org (Juan Gonzalez)
Date: Tue, 05 Jul 2011 16:24:47 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309883087.7.0.832542050927.issue12492@psf.upfronthosting.co.za>


Juan Gonzalez <juan.gonzalez at ti.com> added the comment:

I print 1 before the faulty line and like Jes?s says I'm surprised I get a 1

Description: Build passed
1
Traceback (most recent call last):
  File "wtfibmdom", line 23, in <module>
    if url.find(str) > 0:
AttributeError: 'int' object has no attribute 'find'

----------

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

From report at bugs.python.org  Tue Jul  5 18:27:11 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Jul 2011 16:27:11 +0000
Subject: [issue12492] Inconsistent Python find() behavior
In-Reply-To: <1309816118.48.0.732382168551.issue12492@psf.upfronthosting.co.za>
Message-ID: <1309883231.42.0.418821610108.issue12492@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

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

From report at bugs.python.org  Tue Jul  5 18:33:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 05 Jul 2011 16:33:34 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1309871083.71.0.146155019353.issue6721@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM34ZKz9QvYz2qXESVREHDpoUOk_3m9UmJcPwzi3NY_rAg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>> We can't do that, it would break existing code.
>
> I would argue that such code is already broken.
>

- that's not necessarily true, if your code is carefully designed
- we can't forbid fork() in a multi-threaded application while it's
allowed by POSIX
- backward compatibility is *really* important

>> What do you mean by helper threads?
>
> multiprocessing uses threads behind the scenes to handle queue traffic and such for individual forked processes. It's something I also wasn't aware of until Antoine pointed it out. It also has its own implementation of atfork hooks in an attempt to handle the locking issue.
>

I'm curious as to how you'll manage to implement
multiprocessing.queues without threads.
Please open a dedicated issue for this.

----------

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

From report at bugs.python.org  Tue Jul  5 19:25:37 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdC10Lkg0JDQs9Cw0L/QuNGC0L7Qsg==?=)
Date: Tue, 05 Jul 2011 17:25:37 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>


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

When using asyncore server with UNIX socket, I got 100% CPU usage.
I run modified code example from asyncore doc page.
This code was tested on two systems:

Ubuntu 10.04 2.6.32-32-generic #62-Ubuntu SMP

with two versions of Python:
Python 3.2 (r32:88445, Mar 29 2011, 08:55:36)

Python 3.2.1rc2 (default, Jul  5 2011, 20:33:19) Built from sources

and
Gentoo 2.6.36-hardened-r9 #6 SMP

with Python 3.1.3 (r313:86834, Mar 12 2011, 20:06:24)

I'm not sure, maybe it's because of the characteristics of UNIX socket?

----------
components: Library (Lib)
files: asyncore_test.py
messages: 139898
nosy: Alexey.Agapitov
priority: normal
severity: normal
status: open
title: 100% cpu usage when using asyncore with UNIX socket
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file22585/asyncore_test.py

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

From report at bugs.python.org  Tue Jul  5 19:28:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Jul 2011 17:28:06 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1309886886.19.0.706106043666.issue12502@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/issue12502>
_______________________________________

From report at bugs.python.org  Tue Jul  5 21:18:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 05 Jul 2011 19:18:54 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1309893534.88.0.301564052821.issue12502@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's looping in Lib/asyncore.py:poll

select(4, [3], [3], [3], {30, 0})       = 1 (out [3], left {29, 999994})
select(4, [3], [3], [3], {30, 0})       = 1 (out [3], left {29, 999994})
select(4, [3], [3], [3], {30, 0})       = 1 (out [3], left {29, 999994})

loop sets the Unix domain socket in the writable set, and contrarily to AF_INET/AF_INET6 sockets, bound AF_UNIX SOCK_STREAM sockets are reported as writable before any client connects to them, which triggers the loop.

I've attached a patch which just doesn't add the socket to the writable set if it's in the accepting state.
It fixes the loop, and doesn't seem to cause any regression in test_asyncore, but since it's the first time I'm looking at asyncore's code, I might very well have missed something :-)

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file22586/asyncore_unix_socket.diff

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

From report at bugs.python.org  Tue Jul  5 21:31:48 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 05 Jul 2011 19:31:48 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1309894308.1.0.33597003372.issue12502@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Looks good, the patch seems to fix the problem.
This section of code indicates that the accepting socket shouldn't be in the write set...

def handle_write_event(self):
    if self.accepting:
        # Accepting sockets shouldn't get a write event.
        # We will pretend it didn't happen.
        return

----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Tue Jul  5 22:00:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 20:00:34 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <E1QeBnN-0007vl-6X@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0e5485634817 by Victor Stinner in branch 'default':
Issue #12459: time.sleep() now raises a ValueError if the sleep length is
http://hg.python.org/cpython/rev/0e5485634817

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Jul  5 22:01:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 20:01:46 +0000
Subject: [issue12459] time.sleep(-1.0) behaviour
In-Reply-To: <1309502750.92.0.889855315847.issue12459@psf.upfronthosting.co.za>
Message-ID: <1309896106.45.0.0478912447717.issue12459@psf.upfronthosting.co.za>


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

Tim Lesher agreed to raise an exception ("That makes sense. Better to be consistent within the time API--I know the different semantics of time.clock() have confused people around here."), so I think that everybody agreed to raise an exception.

I commited my commit, let close this issue.

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

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

From report at bugs.python.org  Tue Jul  5 22:36:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 20:36:41 +0000
Subject: [issue12494] subprocess: check_output() doesn't close pipes on error
In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>
Message-ID: <1309898201.29.0.931510946341.issue12494@psf.upfronthosting.co.za>


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

See also issue?#12044 which changed the context manager to call the wait() method.

----------

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

From report at bugs.python.org  Tue Jul  5 22:36:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Jul 2011 20:36:58 +0000
Subject: [issue12044] subprocess.Popen.__exit__ doesn't wait for process end
In-Reply-To: <1304969055.59.0.685744558647.issue12044@psf.upfronthosting.co.za>
Message-ID: <1309898218.7.0.912206279146.issue12044@psf.upfronthosting.co.za>


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

See also issue #12494: "subprocess: check_output() doesn't close pipes on error".

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

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

From report at bugs.python.org  Tue Jul  5 23:12:38 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Jul 2011 21:12:38 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309900358.51.0.619618419675.issue8716@psf.upfronthosting.co.za>


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

That's puzzling. That particular segfault failure is on test_ttk_guionly but test_tk apparently passed earlier in the run and it seems that this buildbot is being run with a window manager connection available (the changes that I added did not raise an exception and the DISPLAY env variable is set).  Further, it's an intermittent segfault.  At the moment, for this buildbot (http://www.python.org/dev/buildbot/all/buildslaves/parc-snowleopard-1), in recent builds only 2.7 builds 202 and 200 have the segfault; 2.7 builds 203 and 201 do not nor do any of the recent 3.2 or 3.x builds.  So, while the fixes I checked in do appear to prevent segfaults in the "headless" operation case (I was able to reproduce and test this on my systems), these two buildbot segfaults appear to have a different root cause.  I am going to temporarily add Ronald's suggested test for 2.7 in hopes of confirming that the window manager connection is indeed not the issue on the buildbot.  I would also be interested in confirmation that what is checked in now prevents the segfaults when running the tests under a headless ssh.

With regard to "untktests.check_tk_availability() creates a Tkinter.Button() in a subprocess. It should maybe try to create a ttk.Button() for test_ttk_guionly instead of Tkinter.Button()": ttk is not necessarily available in older versions of Tk.  The tests are structured to test for Tk availability first and then separately for ttk availability.

----------
resolution: fixed -> 
stage: committed/rejected -> test needed

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

From report at bugs.python.org  Tue Jul  5 23:16:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Jul 2011 21:16:53 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <E1QeCzE-0005no-6X@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 18ce15f841cf by Ned Deily in branch '2.7':
Issue #8716: Add temporary code for 2.7 to help diagnose buildbot failure.
http://hg.python.org/cpython/rev/18ce15f841cf

----------

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

From report at bugs.python.org  Tue Jul  5 23:24:04 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 05 Jul 2011 21:24:04 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1309901044.31.0.159946388061.issue10883@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The failure seems to occur sporadically. I'm looking into it.

----------

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

From report at bugs.python.org  Wed Jul  6 01:14:42 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Tue, 05 Jul 2011 23:14:42 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1309907682.06.0.044959518295.issue12149@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Looking through Antoine's example code. When garbage is collected, the subtype and its tp_dict are cleared before the instance object itself. When the dict is cleared as part of the garbage collection, the methods get deallocated but the method cache is not updated. That way the lookup for the "close" method results in a cache hit for an invalid pointer.

I'm not at all knowledgeable to understand whether it is right for the type dictionary to be cleared before instances of that type (then either the finalizer for IOBase should work around this case, or the cache should be updated beforehand), or there is something to be done to ensure a correct clearing order.

Also I can't think of any other example of a C type, inheritable from Python code, that calls another method in the destructor: is this specific to IO? Please note that the example code fails even when inheriting from the C type directly (_io._IOBase).

----------

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

From report at bugs.python.org  Wed Jul  6 01:16:00 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 05 Jul 2011 23:16:00 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1309907760.1.0.0936254563517.issue12149@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/issue12149>
_______________________________________

From report at bugs.python.org  Wed Jul  6 02:04:02 2011
From: report at bugs.python.org (Dmitriy Gorbachev)
Date: Wed, 06 Jul 2011 00:04:02 +0000
Subject: [issue12482] input() not working correctly on Mac OS X
In-Reply-To: <1309724315.49.0.770156194486.issue12482@psf.upfronthosting.co.za>
Message-ID: <1309910638.60722.YahooMailRC@web160614.mail.bf1.yahoo.com>


Dmitriy Gorbachev <dgorbachev at yahoo.com> added the comment:

Hello Ned

Thank you very much for your time and for your advice where to post questions 
like mine.

I apologise for my mistake: instead of input() there was raw_input() function in 
the book, which works as expected on all platforms.

Best regards

Dmitry

----- Original Message ----
From: Ned Deily <report at bugs.python.org>
To: dgorbachev at yahoo.com
Sent: Sun, July 3, 2011 4:18:35 PM
Subject: [issue12482] input() not working correctly on Mac OS X

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

The test case you've provide is working as expected but the code doesn't make a 
lot of sense as provided.? The function loadDbase sets sys.stdin to a disk file 
but never sets it back again.? If you run this in an interactive interpreter on 
any Unix-like system and call that function, it will leave sys.stdin still 
connected to the disk file which will give unexpected results.? I don't have a 
copy of the book so I don't know how the author recommends to run things but it 
won't work as it stands (also, the function loadDbase is incomplete compared 
with the book's example files).? You can remove the immediate problem by adding 
the following line just before the "return db" at the end of loadDbase:
? ? sys.stdin = sys.__stdin__
That will restore the original value of sys.stdin.

You may want to ask questions like this on either the tutor mailing list or 
comp.lang.python.

http://www.python.org/community/lists/ 

http://docs.python.org/library/sys.html#sys.__stdin__

----------
assignee: ronaldoussoren -> 
components:? -Macintosh
nosy: +ned.deily
resolution:? -> invalid
stage:? -> committed/rejected
status: open -> closed

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

----------

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

From report at bugs.python.org  Wed Jul  6 02:04:19 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 00:04:19 +0000
Subject: [issue5342] packaging: add tests for old versions cleanup on update
In-Reply-To: <1235256230.9.0.667035234316.issue5342@psf.upfronthosting.co.za>
Message-ID: <1309910659.22.0.514873672046.issue5342@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
nosy: +thomas.holmes

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

From report at bugs.python.org  Wed Jul  6 02:16:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Jul 2011 00:16:54 +0000
Subject: [issue11512] adding test suite for cgitb
In-Reply-To: <1300143894.4.0.405606166364.issue11512@psf.upfronthosting.co.za>
Message-ID: <E1QeFnQ-0001N9-VR@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7e0102ec95d4 by Brian Curtin in branch 'default':
Fix #11512. Add an initial test suite for the cgitb, providing 75% coverage.
http://hg.python.org/cpython/rev/7e0102ec95d4

New changeset f362f0053eab by Brian Curtin in branch 'default':
Normalize whitespace for #11512 fix.
http://hg.python.org/cpython/rev/f362f0053eab

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Jul  6 02:19:47 2011
From: report at bugs.python.org (Dmitriy Gorbachev)
Date: Wed, 06 Jul 2011 00:19:47 +0000
Subject: [issue12482] input() not working correctly on Mac OS X
In-Reply-To: <1309723682.92.0.53850862859.issue12482@psf.upfronthosting.co.za>
Message-ID: <1309911584.65149.YahooMailRC@web160609.mail.bf1.yahoo.com>


Dmitriy Gorbachev <dgorbachev at yahoo.com> added the comment:

Hi Amaury,

Thank you very much for your email. 
Actually what happedded is that I mistakenly used input() function in place of 
raw_input() as it is in the book.
raw_input correctly inputs bob and 'bob', while input() inputs correctly 'bob' 
only and complains about bob. 

I will definitely check the usage of input() with bob in Python 3 when I install 
it.

Best regards

Dmitry

----- Original Message ----
From: Amaury Forgeot d'Arc <report at bugs.python.org>
To: dgorbachev at yahoo.com
Sent: Sun, July 3, 2011 4:08:02 PM
Subject: [issue12482] input() not working correctly on Mac OS X

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

You are certainly using Python 2 with code designed for Python 3...
Can you check?

----------
nosy: +amaury.forgeotdarc

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

----------

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

From report at bugs.python.org  Wed Jul  6 02:20:43 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 06 Jul 2011 00:20:43 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1309911643.92.0.461432010165.issue10883@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The problem seems to be that CacheFTPHandler inherits ftp_open() from
FTPHandler - FTPHandler.ftp_open() marks the ftpwrapper object to be closed as
soon as the current transfer is complete. So CacheFTPHandler's cache ends up
full of closed ftpwrappers. I don't have time to put together a solution now,
but I'll work on something over the weekend.

Another thing: CacheFTPHandler.clear_cache() sometimes breaks the cache,
because it fails to clear self.timeout. Is there any reason why the timeouts
need to be in a separate dict from the cached connections themselves? It seems
like a very ugly and error-prone way of organizing things.

----------
assignee:  -> nadeem.vawda

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

From report at bugs.python.org  Wed Jul  6 02:21:17 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Jul 2011 00:21:17 +0000
Subject: [issue11512] adding test suite for cgitb
In-Reply-To: <1300143894.4.0.405606166364.issue11512@psf.upfronthosting.co.za>
Message-ID: <1309911677.88.0.0346593726956.issue11512@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Sorry it took so long to get to this - thanks a lot for the patch, Robbie!

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

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

From report at bugs.python.org  Wed Jul  6 02:23:57 2011
From: report at bugs.python.org (Kenyon Ralph)
Date: Wed, 06 Jul 2011 00:23:57 +0000
Subject: [issue1697175] winreg module for cygwin?
Message-ID: <1309911837.71.0.00128575344608.issue1697175@psf.upfronthosting.co.za>


Changes by Kenyon Ralph <kenyon at kenyonralph.com>:


----------
nosy: +kralph

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

From report at bugs.python.org  Wed Jul  6 02:52:01 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 06 Jul 2011 00:52:01 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1309913521.89.0.866189110445.issue12149@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Invalidating the cache in subtype_clear prevents the "close" method to be called in the collected object. I'm not sure that's the right place where to put the PyType_Modified, but apparently it works.

----------
Added file: http://bugs.python.org/file22587/subtype_clear.patch

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

From report at bugs.python.org  Wed Jul  6 04:12:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Jul 2011 02:12:09 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <E1QeHax-0008OQ-Oe@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b5accd8adc3e by Ned Deily in branch '2.7':
Issue #8716: Back out temporary changeset 18ce15f841cf
http://hg.python.org/cpython/rev/b5accd8adc3e

New changeset b5ac5e25d506 by Ned Deily in branch '2.7':
Issue #8716: Instead of relying on Aqua Tk exceptions to detect lack of
http://hg.python.org/cpython/rev/b5ac5e25d506

New changeset b58b0c5c7e96 by Ned Deily in branch '3.2':
Issue #8716: Instead of relying on Aqua Tk exceptions to detect lack of
http://hg.python.org/cpython/rev/b58b0c5c7e96

New changeset 2f7e353f9e83 by Ned Deily in branch 'default':
Issue #8716: Instead of relying on Aqua Tk exceptions to detect lack of
http://hg.python.org/cpython/rev/2f7e353f9e83

----------

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

From report at bugs.python.org  Wed Jul  6 04:23:56 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Jul 2011 02:23:56 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1309919036.07.0.65635707017.issue8716@psf.upfronthosting.co.za>


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

Despite evidence to the contrary, the temporary MacOS.WMAvailable code showed that there was *not* a window manager connection.  I'm still not sure what the difference in environments is (perhaps it is just due to a different version of Tcl/Tk on the buildbot) nor why the buildbot only fails intermittently.  In any case, I've taken Ronald's suggestion and replaced the Tk-in-a-subprocess sanity check with a ctypes version of what MacOS.WMAvailable did.  Let's see what how well that works.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Wed Jul  6 05:38:44 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 06 Jul 2011 03:38:44 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1309923524.4.0.697192493511.issue12167@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

At least some of the remaining refleaks are caused by lib2to3. lib2to3 uses a logger with the filename as logger name (see `lib2to3.fixer_base.BaseFix.set_filename()`), but as the tests use a temporary file with an arbitrary name, a new logger is created on each test run iteration.

----------
nosy: +Trundle

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

From report at bugs.python.org  Wed Jul  6 05:58:03 2011
From: report at bugs.python.org (Ismael Garrido)
Date: Wed, 06 Jul 2011 03:58:03 +0000
Subject: [issue12503] "with" statement error message is more confusing in Py2.7
In-Reply-To: <1309924683.37.0.310972531328.issue12503@psf.upfronthosting.co.za>
Message-ID: <1309924683.37.0.310972531328.issue12503@psf.upfronthosting.co.za>


New submission from Ismael Garrido <ismaelgfk at gmail.com>:

Using the "with" statement wrongly results in a confusing error message.

Code (originally written by Alex Gaynor):

class Timer(object):
    def __enter__(self):
        self.start = time.time()
    def __exit__(self, exc_type, exc_val, tb):
        print "Section time: ", time.time() - self.start

#Note the error here, I call the class, not an instance
with Timer:
    pass


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


Compare the Python 2.6 error:

ismael at chaos:~/Escritorio$ python bad.py 
Traceback (most recent call last):
  File "bad.py", line 8, in <module>
    with Timer:
TypeError: unbound method __enter__() must be called with Timer instance as first argument (got nothing instead)

Against Python 2.7:

ismael at chaos:~/Escritorio$ python2.7 bad.py 
Traceback (most recent call last):
  File "bad.py", line 8, in <module>
    with Timer:
AttributeError: __exit__

----------
components: Interpreter Core
messages: 139918
nosy: Ismael.Garrido
priority: normal
severity: normal
status: open
title: "with" statement error message is more confusing in Py2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul  6 06:07:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Jul 2011 04:07: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: <1309925252.09.0.328174451902.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If someone is calling release() on all of their views (including slices) than they won't have any problems. The only way they can get into trouble is if they have a slice or copy that they *aren't* explicitly releasing, and in that case they *already* have a problem and we're just picking it up sooner (although, in the case of CPython, refcounting will likely take care of it, just as it does for similar problems with files).

This is why I suggested that we should start exposing the source object at the Python level as an attribute of memoryview objects. Then people can decide for themselves if they want a "view-of-a-view" by slicing/copying the memoryview directly or a new, independent view by going back to the original object.

----------

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

From report at bugs.python.org  Wed Jul  6 06:16:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Jul 2011 04:16:49 +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: <1309925809.94.0.388727756115.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oops, Antoine's right, the release() semantics in the patch are broken, albeit for the precisely opposite reasons: that example will actually blow up with BufferError inside some_library_function().

I withdraw my objection - Antoine's right that release() on a memoryview object has to just mean "drop the reference to the ManagedBuffer instance". Calling release() when there are actual *exported* buffers outstanding should still trigger BufferError though (slices and copies don't count in that case, as they'll have their own independent references to the ManagedBuffer instance).

----------

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

From report at bugs.python.org  Wed Jul  6 06:21:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Jul 2011 04:21:37 +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: <1309926097.0.0.510751966682.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sorry, I mischaracterised Antoine's suggestion in my last comment. It's more in the nature of ManagedBuffer exposing two APIs:

1. request_release(): tells ManagedBuffer "if I have the last reference, release the buffer now".

2. release(): immediately releases the buffer, or triggers SystemError if there are additional references to the buffer. 

memoryview.release() would call the first method before dropping the reference to the buffer.

----------

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

From report at bugs.python.org  Wed Jul  6 06:29:39 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:29:39 +0000
Subject: [issue12504] Uninstall has disabled windows tests
Message-ID: <1309926579.84.0.641208908004.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
assignee: tarek
components: Distutils2
nosy: alexis, eric.araujo, tarek, thomas.holmes
priority: normal
severity: normal
status: open
title: Uninstall has disabled windows tests
versions: Python 3.3

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

From report at bugs.python.org  Wed Jul  6 06:34:41 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:34:41 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>


New submission from Thomas Holmes <thomas at devminded.com>:

Functions test_uninstall.test_uninstall and test_uninstall.test_remove_issue were disabled for win32. Upon enabling them they generated failures.

I have worked up a patch that refactors a packaging.Distribution function _get_records from using a generator to returning a list. The generator function was holding open the RECORD file that it is trying to delete, resulting in failure.

I've tried to follow the protocol for a distutils2 patch as shown here (http://wiki.python.org/moin/Distutils/Contributing) so hopefully I've got this remote repository pointing correct.

> packaging.tests.test_uninstall -v
test_remove_issue (__main__.UninstallTestCase) ... ERROR
FAIL
test_uninstall (__main__.UninstallTestCase) ... ERROR
FAIL
test_uninstall_unknow_distribution (__main__.UninstallTestCase) ... ok

======================================================================
ERROR: test_remove_issue (__main__.UninstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\python\dev\cpython\lib\packaging\tests\test_uninstall.py", line 48, in tearDown
    super(UninstallTestCase, self).tearDown()
  File "D:\python\dev\cpython\lib\packaging\tests\support.py", line 134, in tearDown
    shutil.rmtree(self._basetempdir)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 284, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "D:\python\dev\cpython\lib\shutil.py", line 282, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'd:\\temp\\tmpy
6drm5\\tmp6htvi1\\Lib\\site-packages\\Meh-0.1.dist-info\\RECORD'

======================================================================
ERROR: test_uninstall (__main__.UninstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\python\dev\cpython\lib\packaging\tests\test_uninstall.py", line 48, in tearDown
    super(UninstallTestCase, self).tearDown()
  File "D:\python\dev\cpython\lib\packaging\tests\support.py", line 134, in tearDown
    shutil.rmtree(self._basetempdir)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 279, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "D:\python\dev\cpython\lib\shutil.py", line 284, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "D:\python\dev\cpython\lib\shutil.py", line 282, in rmtree
    os.remove(fullname)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'd:\\temp\\tmp4
23fq4\\tmpp2v6uq\\Lib\\site-packages\\Foo-0.1.dist-info\\RECORD'

======================================================================
FAIL: test_remove_issue (__main__.UninstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\python\dev\cpython\lib\packaging\tests\test_uninstall.py", line 124, in test_remove_issue
    self.assertTrue(remove('Meh', paths=[install_lib]))
AssertionError: False is not true

======================================================================
FAIL: test_uninstall (__main__.UninstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\python\dev\cpython\lib\packaging\tests\test_uninstall.py", line 102, in test_uninstall
    self.assertTrue(remove('Foo', paths=[install_lib]))
AssertionError: False is not true

----------------------------------------------------------------------
Ran 3 tests in 0.120s

FAILED (failures=2, errors=2)
[145911 refs]

D:\python\dev\cpython\PCbuild>

----------
hgrepos: +37

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

From report at bugs.python.org  Wed Jul  6 06:35:17 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:35:17 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309926917.96.0.0802271231424.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22588/f333cd40cd56.diff

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

From report at bugs.python.org  Wed Jul  6 06:35:35 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:35:35 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309926935.81.0.755557391085.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Removed file: http://bugs.python.org/file22588/f333cd40cd56.diff

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

From report at bugs.python.org  Wed Jul  6 06:43:29 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:43:29 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309927409.31.0.240150367921.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file22589/dd470b122f32.diff

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

From report at bugs.python.org  Wed Jul  6 06:52:23 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:52:23 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309927943.71.0.647947395273.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Removed file: http://bugs.python.org/file22589/dd470b122f32.diff

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

From report at bugs.python.org  Wed Jul  6 06:52:47 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:52:47 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309927967.31.0.553976406204.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file22590/dcd66ae649b1.diff

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

From report at bugs.python.org  Wed Jul  6 06:53:42 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 04:53:42 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309928022.58.0.602908925064.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Removed file: http://bugs.python.org/file22590/dcd66ae649b1.diff

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

From report at bugs.python.org  Wed Jul  6 06:59:21 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 06 Jul 2011 04:59:21 +0000
Subject: [issue4768] email.generator.Generator object bytes/str crash -
	b64encode() bug?
In-Reply-To: <1230571301.08.0.30132908931.issue4768@psf.upfronthosting.co.za>
Message-ID: <1309928361.76.0.561724063309.issue4768@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/issue4768>
_______________________________________

From report at bugs.python.org  Wed Jul  6 07:01:33 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Wed, 06 Jul 2011 05:01:33 +0000
Subject: [issue12504] Uninstall has disabled windows tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1309928493.03.0.971315050023.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file22591/dcd66ae649b1-2.diff

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

From report at bugs.python.org  Wed Jul  6 07:48:04 2011
From: report at bugs.python.org (John)
Date: Wed, 06 Jul 2011 05:48:04 +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: <1309931284.78.0.0691809483413.issue11230@psf.upfronthosting.co.za>


John <jh45dev at gmail.com> added the comment:

Sorry for the long delay.

haypo wrote:
  Can you propose a sentence which is more clear about bytes/Unicode?

On this page:
http://www.python.org/download/releases/3.2/
is this line:
"- countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables)"

How about adding to that line something like:
" on UNIX; but on Windows the path to and name of each module you import can contain only characters that are in the ANSI codepage that your Windows is using"

and maybe
" (will be fixed in Python 3.3)"

and maybe (or not) also something like:
" (ANSI codepage = basic latin + other characters of only your own language group)"

-- jh

----------

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

From report at bugs.python.org  Wed Jul  6 08:42:49 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jul 2011 06:42:49 +0000
Subject: [issue11436] Clarify struct doc for format 's',
	when it is mentioned without numeric prefix
In-Reply-To: <1299522578.2.0.51699411527.issue11436@psf.upfronthosting.co.za>
Message-ID: <1309934569.53.0.778177002063.issue11436@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Is this not implicit? Do we really need this stmt? I am -0 on this. If you agree, you can close this issue.

----------
nosy: +orsenthil
title: Clarify struct doc for format 's'. -> Clarify struct doc for format 's', when it is mentioned without numeric prefix

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

From report at bugs.python.org  Wed Jul  6 08:58:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 06 Jul 2011 06:58:18 +0000
Subject: [issue12493] subprocess: Popen.communicate() doesn't handle EINTR in
	some cases
In-Reply-To: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>
Message-ID: <1309935498.29.0.464401254003.issue12493@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Out of curiosity, how could SIGALRM be missing on a Unix system?
Maybe you mean something like
@unittest.skipUnless(hasattr(errno, EINTR),
                     "Requires errno.EINTR")

----------
nosy: +neologix

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

From report at bugs.python.org  Wed Jul  6 09:01:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 06 Jul 2011 07:01:01 +0000
Subject: [issue11436] Clarify struct doc for format 's',
	when it is mentioned without numeric prefix
In-Reply-To: <1299522578.2.0.51699411527.issue11436@psf.upfronthosting.co.za>
Message-ID: <1309935661.03.0.32281945464.issue11436@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A default of 1 in not implicit for output formatting.
%s and {:s} mean however long needed, not %1s or {:1s}

----------
versions:  -Python 3.1

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

From report at bugs.python.org  Wed Jul  6 09:41:39 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 06 Jul 2011 07:41:39 +0000
Subject: [issue11436] Clarify struct doc for format 's',
	when it is mentioned without numeric prefix
In-Reply-To: <1309935661.03.0.32281945464.issue11436@psf.upfronthosting.co.za>
Message-ID: <20110706074134.GA2986@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

That is for the string formatting character, correct?

In this issue, we are talking about format character for struct and
not just 's' but 'c','h','b','i' all without numeric prefix imply
single value.

----------

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

From report at bugs.python.org  Wed Jul  6 10:50:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Jul 2011 08:50:51 +0000
Subject: [issue12493] subprocess: Popen.communicate() doesn't handle EINTR in
	some cases
In-Reply-To: <1309816990.23.0.880296531528.issue12493@psf.upfronthosting.co.za>
Message-ID: <1309942251.22.0.578877754183.issue12493@psf.upfronthosting.co.za>


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

> Out of curiosity, how could SIGALRM be missing on a Unix system?

It is only missing on Windows.

----------

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

From report at bugs.python.org  Wed Jul  6 10:55:49 2011
From: report at bugs.python.org (Nir Aides)
Date: Wed, 06 Jul 2011 08:55:49 +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: <1309942549.72.0.64681359745.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> Would you like to work on a patch to add an atfork mechanism?

I will start with an attempt to generate a summary "report" on this rabbit hole of a problem, the views and suggestions raised by people here and what we may expect from atfork approach, its limitations, etc... I will also take a deeper look into the code.

Hopefully my brain will not deadlock or fork while I am at it.

more words, I know...

----------

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

From report at bugs.python.org  Wed Jul  6 12:54:57 2011
From: report at bugs.python.org (yoch)
Date: Wed, 06 Jul 2011 10:54:57 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>


New submission from yoch <yoch.melka at gmail.com>:

Hi,

I'm using sys.argv to retrieve files and process them on the command line.
Wildcards arguments (like : test.py *.txt) works fine under Linux (expanded), but not on Windows.
It also affects the fileinput functions.
The solution is to change the compilation options msvc, as mentioned here:
http://msdn.microsoft.com/en-us/library/8bch7bkk.aspx

Regards,
yoch

----------
components: Windows
files: test_argv_1.py
messages: 139930
nosy: yoch.melka
priority: normal
severity: normal
status: open
title: python interpreter not handle wildards properly
versions: Python 3.2
Added file: http://bugs.python.org/file22592/test_argv_1.py

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

From report at bugs.python.org  Wed Jul  6 14:19:43 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Jul 2011 12:19:43 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110706121933.GA78536@sherwood.local>


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

So sorry that i'm stressing this, hopefully it's the final message.
Apples iterative kernel-update strategy resulted in these versions:

    14:02 ~/tmp $ /usr/sbin/sysctl kern.version
    kern.version: Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386
    14:02 ~/tmp $ gcc -o zt osxversion.c -framework CoreServices
    14:03 ~/tmp $ ./zt 
    OS X version: 10.6.8
    apple_osx_needs_fullsync: -1

I.e. the new patch uses >10.7.0 or >=10.6.8 to avoid that
FULLFSYNC disaster (even slower than the Macrohard memory
allocator during "Wintel" partnership!), and we end up as:

    14:03 ~/src/cpython $ ./python.exe -E -Wd -m test -r -w -uall test_mmap
    Using random seed 8466468
    [1/1] test_mmap
    1 test OK.

P.S.: i still have no idea how to do '-framework CoreServices'
regulary.  Like i've said in #11046 i never used GNU Autoconf/M4,
sorry.  You know.  Maybe the version check should be moved
somewhere else and simply be exported, even replacing the stuff
from platform.py?  I don't know.  Bye.
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------
Added file: http://bugs.python.org/file22593/11277.apple-fix-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/mmap.rst b/Doc/library/mmap.rst
--- a/Doc/library/mmap.rst
+++ b/Doc/library/mmap.rst
@@ -88,7 +88,8 @@
 
    To ensure validity of the created memory mapping the file specified
    by the descriptor *fileno* is internally automatically synchronized
-   with physical backing store on Mac OS X and OpenVMS.
+   with physical backing store on operating systems where this is
+   necessary, e.g. OpenVMS, and some buggy versions of Mac OS X.
 
    This example shows a simple way of using :class:`mmap`::
 
diff --git a/Modules/mmapmodule.c b/Modules/mmapmodule.c
--- a/Modules/mmapmodule.c
+++ b/Modules/mmapmodule.c
@@ -25,6 +25,8 @@
 #define UNIX
 # ifdef __APPLE__
 #  include <fcntl.h>
+
+#  include <CoreServices/CoreServices.h>
 # endif
 #endif
 
@@ -65,6 +67,44 @@
 #define my_getpagesize getpagesize
 #endif
 
+# ifdef __APPLE__
+static void
+apple_osx_needs_fullsync(long *use_fullsync)
+{
+    /* Issue #11277: mmap(2) bug with >32 bit sparse files.
+     * Apple fixed the bug before announcement of OS X "Lion", but since we
+     * need to handle buggy versions, perform a once-only check to see if the
+     * running kernel requires the expensive sync.  Fixed in 10.6.8, 10.7++.
+     * >0: F_FULLSYNC is required, <0: kernel has mmap(2) bug fixed */
+    SInt32 ver;
+    *use_fullsync = 1;
+
+    if (Gestalt(gestaltSystemVersion, &ver) != noErr)
+        goto jleave;
+    /* SystemVersion(Major|Minor|BugFix) available at all? */
+    if (ver < 0x1040)
+        goto jleave;
+    if (Gestalt(gestaltSystemVersionMajor, &ver) != noErr)
+        goto jleave;
+    if (ver > 10)
+        goto jgood;
+    if (Gestalt(gestaltSystemVersionMinor, &ver) != noErr)
+        goto jleave;
+    if (ver >= 7)
+        goto jgood;
+    if (ver < 6)
+        goto jleave;
+    if (Gestalt(gestaltSystemVersionBugFix, &ver) != noErr)
+        goto jleave;
+    if (ver < 8)
+        goto jleave;
+jgood:
+    *use_fullsync = -1;
+jleave:
+    return;
+}
+# endif /* __APPLE__ */
+
 #endif /* UNIX */
 
 #include <string.h>
@@ -1150,8 +1190,14 @@
 #ifdef __APPLE__
     /* Issue #11277: fsync(2) is not enough on OS X - a special, OS X specific
        fcntl(2) is necessary to force DISKSYNC and get around mmap(2) bug */
-    if (fd != -1)
-        (void)fcntl(fd, F_FULLFSYNC);
+    if (fd != -1) {
+        /* (GIL protected) */
+        static long use_fullsync /*= 0*/;
+        if (!use_fullsync)
+            apple_osx_needs_fullsync(&use_fullsync);
+        if (use_fullsync > 0)
+            (void)fcntl(fd, F_FULLFSYNC);
+    }
 #endif
 #ifdef HAVE_FSTAT
 #  ifdef __VMS

From report at bugs.python.org  Wed Jul  6 14:21:27 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 06 Jul 2011 12:21:27 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1309954887.15.0.232574593604.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file22281/11277.apple-fix-2.diff

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

From report at bugs.python.org  Wed Jul  6 14:39:20 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 06 Jul 2011 12:39:20 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1309880753.3683.36.camel@localhost.localdomain>
Message-ID: <20110706123712.GA30419@sleipnir.bytereef.org>


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

Antoine is right, this needs to be fixed. I think that for *practical*
purposes, the existing release() method already behaves like a tryrelease()
method:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: Existing exports of data: object cannot be re-sized
>>>

So while m1.release() in fact *does* release a buffer, the desired
effect (freeing up 'b' for subsequent operations) only happens
after also calling m2.release(). This applies to Python and NumPy
objects.

With this amount of complexity, it might be a good idea to separate
refcounting and exports, like so:

typedef struct {
    PyObject_HEAD
    int released;
    Py_ssize_t exports; /* total number of exports */
    Py_buffer master;
} PyManagedBufferObject;

typedef struct {
    PyObject_HEAD
    PyManagedBufferObject *mbuf;
    Py_ssize_t shape[Py_MEMORYVIEW_MAXSTATIC];
    Py_ssize_t strides[Py_MEMORYVIEW_MAXSTATIC];
    Py_ssize_t suboffsets[Py_MEMORYVIEW_MAXSTATIC];
    int released; /* for clarity in the code */
    Py_ssize_t exports; /* buffer exports */
    Py_buffer view;
} PyMemoryViewObject;

Then it is possible for a MemoryView to call mbuf_release() from
memory_release() if self->exports == 0 and --self->mbuf->exports == 0.

So, if I understand Antoine correctly, in following graph m1, m2 and
m4 could mark themselves as 'released' and decrement self->mbuf->exports.
This could happen in any order.

What should happen with m2.release()? Raising would be odd here as well,
since Pauli stated earlier that some people might actually construct
new objects from an exported buffer.

m2 could mark itself as 'release_pending', and henceforth only accept
releasebuffer requests from b1, b2 and x1. Once those are all in, it
releases itself properly and sends the message to mbuf.

'release_pending' could be expressed as (self->released && self->exports > 0).

                        ManagedBuffer (mbuf)
                             |
             -----------------------------------
             |                                 |
             m1 (private arrays)              m3 (private arrays)
             |                                 |
             m2                               m4 (private arrays)
             |
     -----------------
     |       |       |
     |      b1      b2 (regular temporary buffer exports)
     |
     x1 (new object constructed from a buffer export)

Antoine, was this roughly your suggestion?

----------

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

From report at bugs.python.org  Wed Jul  6 14:42:23 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 06 Jul 2011 12:42: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: <1309956143.07.0.342972945457.issue10181@psf.upfronthosting.co.za>


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

[The first part of the message again, this time via the web interface.]

Antoine is right, this needs to be fixed. I think that for *practical*
purposes, the existing release() method already behaves like a tryrelease()
method:


>>> b = bytearray(b'123456789')
>>> m1 = memoryview(b)
>>> m2 = memoryview(m1)
>>> m1.release()
>>> b.append(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: Existing exports of data: object cannot be re-sized
>>>


So while m1.release() in fact *does* release a buffer, the desired
effect (freeing up 'b' for subsequent operations) only happens
after also calling m2.release(). This applies to Python and NumPy
objects.

----------

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

From report at bugs.python.org  Wed Jul  6 14:48:57 2011
From: report at bugs.python.org (bjorn lofdahl)
Date: Wed, 06 Jul 2011 12:48:57 +0000
Subject: [issue12506] NIS module cant handle multiple NIS map entries for the
	same GID
In-Reply-To: <1309956537.93.0.737876319543.issue12506@psf.upfronthosting.co.za>
Message-ID: <1309956537.93.0.737876319543.issue12506@psf.upfronthosting.co.za>


New submission from bjorn lofdahl <bjorn.lofdahl at gmail.com>:

I think i have found an issue with the module that is only visible on larger sites that are using multiple group entries for the same group in the NIS maps. This comes from the bug that NIS can only handle 1024 chars per line, so if a group has more members that exceeds 1024 chars, a new line is added with the same GID and NAME. yp tools handles this fine, it simply reports several "lines" for the same group. For ex:

> ypcat group | grep FOO | cut -d ':' -f 1-3
FOO:x:17776
FOO:x:17776
FOO:x:17776
FOO:x:17776
FOO:x:17776

when i do the same using the python NIS module it only gives me the users for one of the maps for this group. I guess the "correct" behavior from the module should be to concatenate/append all users from all the maps for each specific group.

----------
messages: 139934
nosy: bjorn.lofdahl
priority: normal
severity: normal
status: open
title: NIS module cant handle multiple NIS map entries for the same GID
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Jul  6 15:01:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Jul 2011 13:01:03 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <20110706123712.GA30419@sleipnir.bytereef.org>
Message-ID: <1309957213.3694.9.camel@localhost.localdomain>


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

Le mercredi 06 juillet 2011 ? 12:39 +0000, Stefan Krah a ?crit :
> Antoine, was this roughly your suggestion?

I think so (!), but I also agree with Nick that raising BufferError when
calling release() on a memoryview with exports is a reasonable
alternative.

----------

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

From report at bugs.python.org  Wed Jul  6 15:16:44 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Jul 2011 13:16: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: <1309958204.04.0.646143482692.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, the reason my originally proposed semantics were wrong is because copying (or slicing) a memoryview object and then explicitly releasing that object would always fail through no fault of that code. That would be broken and the only way to fix it is to allow the release() call but not actually call the ReleaseBuffer API until all the buffer references are gone.

Exports are different - whenever you copy or slice a memoryview, you get a new memoryview object with the export count set to zero, so it is reasonable to require that anyone that wants to explicitly release the memoryview's buffer reference make sure that there aren't any exports hanging around. Keep in mind that memoryview copies and slices don't increase the export count, as those will refer directly back to the original managed buffer.

+1 on tracking buffer exports explicitly rather than relying solely on playing games with refcounts though - while technically redundant in the ManagedBuffer case, I agree it will make the code far more self-explanatory.

----------

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

From report at bugs.python.org  Wed Jul  6 16:31:38 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 06 Jul 2011 14:31:38 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309962698.27.0.0482442430004.issue12505@psf.upfronthosting.co.za>


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

But what if you don't want the expansion done? I always invoke python from cygwin's bash shell, and sometimes I tell the shell not to expand the arguments, such as:

python \*
or
python '*'

I wouldn't want python (or rather the C runtime) to do the expansion in this case, and I don't see how it could know not to do it.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Wed Jul  6 19:10:19 2011
From: report at bugs.python.org (yoch)
Date: Wed, 06 Jul 2011 17:10:19 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309972219.32.0.204414763426.issue12505@psf.upfronthosting.co.za>


yoch <yoch.melka at gmail.com> added the comment:

Escape the wildcard like '*' will work (like on Linux).

I think \* will not work...

----------

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

From report at bugs.python.org  Wed Jul  6 19:14:52 2011
From: report at bugs.python.org (LMO)
Date: Wed, 06 Jul 2011 17:14:52 +0000
Subject: [issue12507] tkSimpleDialog problem
In-Reply-To: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>
Message-ID: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>


New submission from LMO <raycores at gmail.com>:

tkSimpleDialog displays blank rectangle and hangs with version 2.7.  Works fine on version 2.6.  In attached program, click on button labeled "Press this Button" which will call tkSimpleDialog.

----------
components: Tkinter
files: ACSDtest.py
messages: 139939
nosy: rzn8tr
priority: normal
severity: normal
status: open
title: tkSimpleDialog problem
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22594/ACSDtest.py

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

From report at bugs.python.org  Wed Jul  6 19:21:29 2011
From: report at bugs.python.org (LMO)
Date: Wed, 06 Jul 2011 17:21:29 +0000
Subject: [issue12507] tkSimpleDialog problem
In-Reply-To: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>
Message-ID: <1309972889.91.0.387662463372.issue12507@psf.upfronthosting.co.za>


LMO <raycores at gmail.com> added the comment:

Omitted platform info:
MacBook Pro, 2.4 GHz Intel Core 2 Duo, 4 GB RAM, OS X 10.7 build 11A511
also confirmed on OS X 10.6 (Snow Leopard)

----------

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

From report at bugs.python.org  Wed Jul  6 19:28:20 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 06 Jul 2011 17:28:20 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309973300.42.0.356809799915.issue12505@psf.upfronthosting.co.za>


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

Both of them work under cygwin. My point is that neither would work if the C runtime expanded command line arguments.

----------

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

From report at bugs.python.org  Wed Jul  6 20:49:35 2011
From: report at bugs.python.org (yoch)
Date: Wed, 06 Jul 2011 18:49:35 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309978175.87.0.797902341768.issue12505@psf.upfronthosting.co.za>


yoch <yoch.melka at gmail.com> added the comment:

'setargv.obj' not C runtime, it's only static library to allow expanding wildcards arguments received by the program. (MinGW uses approximately the same principle for executables compilation)

And, it's not appropriate to tell people who need this feature (arguments expanding) to work only with cygwin ...

----------

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

From report at bugs.python.org  Wed Jul  6 20:58:18 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 06 Jul 2011 18:58:18 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309978698.84.0.292192301099.issue12505@psf.upfronthosting.co.za>


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

I'm not suggesting they use cygwin. I'm saying that if they do use cygwin that something they currently do would stop working. There would be no way to pass a command line parameter of "*" to python, at least without adding more escaping (hard to say, documentation of setargv.obj is sparse).

Of course this would be true from any shell, I'm just familiar with the syntax of doing so under bash.

While it might be a separate .obj file, I believe it's still part of the logical C runtime that gets invoked before python's main(). Or am I missing something? (entirely possible, it's been a while since I've used setargv.obj)

----------

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

From report at bugs.python.org  Wed Jul  6 21:12:31 2011
From: report at bugs.python.org (yoch)
Date: Wed, 06 Jul 2011 19:12:31 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309979551.36.0.929737901045.issue12505@psf.upfronthosting.co.za>


yoch <yoch.melka at gmail.com> added the comment:

With cmd and program compiled with setargv.obj, 'command *' is expanded, but not 'command "*"'. So, it's possible to escape them normally.

[q]
While it might be a separate .obj file, I believe it's still part of the logical C runtime that gets invoked before python's main(). Or am I missing something? (entirely possible, it's been a while since I've used setargv.obj)
[/q]
I dont't know. But what difference does it make, after all?
( I'm not sure I understand, my english is poor ;) )

----------

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

From report at bugs.python.org  Wed Jul  6 21:19:27 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 06 Jul 2011 19:19:27 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309979967.97.0.969072365184.issue12505@psf.upfronthosting.co.za>


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

> I dont't know. But what difference does it make, after all?

I just want to make sure it's something that happens automatically and wouldn't require a change to python's C code.

To the other point, someone who currently uses:
python '*'
would need to change to:
python '"*"'

I'm just pointing out that it's a change for some users, and might break some existing usage of python. I can't say whether or not that's a big problem or not.

----------

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

From report at bugs.python.org  Wed Jul  6 21:23:08 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Jul 2011 19:23:08 +0000
Subject: [issue12503] "with" statement error message is more confusing in Py2.7
In-Reply-To: <1309924683.37.0.310972531328.issue12503@psf.upfronthosting.co.za>
Message-ID: <1309980188.32.0.828019190754.issue12503@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The message is not inaccurate, but indeed misleading. In wonder what to do considering the traditional message of AttributeError is simply the missing attribute.

----------
nosy: +benjamin.peterson
priority: normal -> low

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

From report at bugs.python.org  Wed Jul  6 21:57:25 2011
From: report at bugs.python.org (LMO)
Date: Wed, 06 Jul 2011 19:57:25 +0000
Subject: [issue12507] tkSimpleDialog problem
In-Reply-To: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>
Message-ID: <1309982245.44.0.291910835144.issue12507@psf.upfronthosting.co.za>


LMO <raycores at gmail.com> added the comment:

I confirmed that the problem does not exist under Win XP using python 2.7.2.

----------

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

From report at bugs.python.org  Wed Jul  6 21:57:49 2011
From: report at bugs.python.org (LMO)
Date: Wed, 06 Jul 2011 19:57:49 +0000
Subject: [issue12507] tkSimpleDialog problem
In-Reply-To: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>
Message-ID: <1309982269.43.0.00827651563247.issue12507@psf.upfronthosting.co.za>


Changes by LMO <raycores at gmail.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh -Tkinter
nosy: +ronaldoussoren

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

From report at bugs.python.org  Wed Jul  6 22:04:07 2011
From: report at bugs.python.org (Sebastian Ramacher)
Date: Wed, 06 Jul 2011 20:04:07 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309982647.35.0.652025835453.issue12505@psf.upfronthosting.co.za>


Sebastian Ramacher <sebastinas at users.sourceforge.net> added the comment:

That is definitely not python's job. That is the duty of your shell and python should never expand that.

And it would lead to platform specific behavior as one can see with the following script:

import sys
import subprocess

if __name__ == "__main__":
  if len(sys.argv) == 1:
    subprocess.Popen([sys.executable, __file__, "foo", "*"])
  else:
    print sys.argv[1:]

With setargv.obj the argument would be expanded on Windows whereas on any other platform it just prints [foo, *].

----------
nosy: +sebastinas

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

From report at bugs.python.org  Wed Jul  6 22:28:27 2011
From: report at bugs.python.org (yoch)
Date: Wed, 06 Jul 2011 20:28:27 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309984107.96.0.169483961986.issue12505@psf.upfronthosting.co.za>


yoch <yoch.melka at gmail.com> added the comment:

Okay. Thanks :)

----------

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

From report at bugs.python.org  Wed Jul  6 22:29:46 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 06 Jul 2011 20:29:46 +0000
Subject: [issue6090] zipfile: Bad error message when zipping a with timestamp
	before 1980
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1309984186.81.0.0707787563785.issue6090@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Retitled to reflect that the error message should be enhanced.

Attached a patch for 2.7 that raises ValueError for timestamps before 1980, documents that 1980 or later is required, and adds some tests.

----------
keywords: +needs review, patch
nosy: +petri.lehtinen
stage: test needed -> patch review
title: zipfile DeprecationWarning Python in 2.6, failure in 2.7 -> zipfile: Bad error message when zipping a with timestamp before 1980
versions:  -Python 2.6
Added file: http://bugs.python.org/file22595/zipfile_timestamps_before_1980.patch

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

From report at bugs.python.org  Wed Jul  6 22:30:18 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 06 Jul 2011 20:30:18 +0000
Subject: [issue6090] zipfile: Bad error message when zipping a file with
	timestamp before 1980
In-Reply-To: <1243011059.87.0.0917631314165.issue6090@psf.upfronthosting.co.za>
Message-ID: <1309984218.01.0.528909345195.issue6090@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
title: zipfile: Bad error message when zipping a with timestamp before 1980 -> zipfile: Bad error message when zipping a file with timestamp before 1980

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

From report at bugs.python.org  Wed Jul  6 22:32:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 06 Jul 2011 20:32:53 +0000
Subject: [issue12198] zipfile.py:1047: DeprecationWarning: 'H' format requires
	0 <= number <= 65535
In-Reply-To: <1306521866.64.0.0795641748962.issue12198@psf.upfronthosting.co.za>
Message-ID: <1309984373.49.0.564793865885.issue12198@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Setting as duplicate of #6090.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> zipfile: Bad error message when zipping a file with timestamp before 1980

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

From report at bugs.python.org  Wed Jul  6 22:41:28 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Jul 2011 20:41:28 +0000
Subject: [issue12505] python interpreter not handle wildards properly
In-Reply-To: <1309949697.3.0.655246491715.issue12505@psf.upfronthosting.co.za>
Message-ID: <1309984888.01.0.568883028625.issue12505@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Wed Jul  6 23:11:22 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Jul 2011 21:11:22 +0000
Subject: [issue12507] tkSimpleDialog problem
In-Reply-To: <1309972491.94.0.855067439806.issue12507@psf.upfronthosting.co.za>
Message-ID: <1309986682.3.0.36966167216.issue12507@psf.upfronthosting.co.za>


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

The problem is not with Python 2.7 per se. It's a problem when running on OS X with a Python linked with the current Aqua Cocoa Tk 8.5, such as the ActiveState Tcl/Tk.  Your test case works OK when using the current 32-bit-only Python 2.7.2 from python.org which links with the older Aqua Carbon Tk 8.4.  Unfortunately, this is not the first of these kinds of problems reported.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Jul  6 23:20:32 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Wed, 06 Jul 2011 21:20:32 +0000
Subject: [issue12178] csv writer doesn't escape escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1309987232.23.0.778852890002.issue12178@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

I looked at this and tried to provide a patch + tests. Please review.

The bug is that a writer can use writerow on some input data but if a reader with the same dialect reads them back they are different from the input ones. This happens when the input data contains escapechar. Contrary to msg136881, this happens regardless whether doublequote is True or False.

The docs say "On reading, the escapechar removes any special meaning from the following character". Therefore, I understand that on writing, escapechar must always be escaped by itself. If that doesn't happen, when reading it back, escapechar alters the thing that follows it instead of counting as escapechar which is precisely what this bug is about.

----------
hgrepos: +38
nosy: +catalin.iacob

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

From report at bugs.python.org  Wed Jul  6 23:21:25 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Wed, 06 Jul 2011 21:21:25 +0000
Subject: [issue12178] csv writer doesn't escape escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1309987285.32.0.498406617004.issue12178@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22596/0eb420ce6567.diff

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

From report at bugs.python.org  Thu Jul  7 00:45:49 2011
From: report at bugs.python.org (Saul Spatz)
Date: Wed, 06 Jul 2011 22:45:49 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>


New submission from Saul Spatz <saul.spatz at gmail.com>:

The attached script produces the output 

'A\ufffdBC\ufffd'
'A\ufffdBC'

although it seems to me that both lines should be the same.  The first line is correct, I think, since the <F4> at the end is a maximal subpart of an ill-formed subsequence, according to the definition in the Unicode standard.

----------
components: Unicode
files: fffd.py
messages: 139954
nosy: spatz123
priority: normal
severity: normal
status: open
title: Codecs Anomaly
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22597/fffd.py

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

From report at bugs.python.org  Thu Jul  7 00:50:10 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Wed, 06 Jul 2011 22:50:10 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1309992610.94.0.604969999875.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

This patch differs from the previous one; its goal is to bring the actual behavior of the interpreter into line with the documentation (with the exception of using only decimal integers, rather than any integers, wherever the documentation for str.format currently has "integer": this does, however, conform with current behavior).

----------
Added file: http://bugs.python.org/file22598/strformat-as-documented.diff

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

From report at bugs.python.org  Thu Jul  7 00:52:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Jul 2011 22:52:30 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1309992750.49.0.460330606176.issue12508@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/issue12508>
_______________________________________

From report at bugs.python.org  Thu Jul  7 00:53:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Jul 2011 22:53:14 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1309992794.85.0.226333315894.issue12508@psf.upfronthosting.co.za>


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

I confirm, there is a bug in codecs.StreamReader.

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

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

From report at bugs.python.org  Thu Jul  7 00:55:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Jul 2011 22:55:18 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1309992918.18.0.984646129742.issue12508@psf.upfronthosting.co.za>


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

You should use the io module, it doesn't have the bug :)

----------

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

From report at bugs.python.org  Thu Jul  7 00:59:51 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Wed, 06 Jul 2011 22:59:51 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1309993191.49.0.608781080771.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

And here is a patch for Greg Ewing's proposal: http://mail.python.org/pipermail/python-dev/2011-June/111934.html

Again, decimal integers rather than any kind of integers are used.

Both patches alter the exceptions expected in various places in test_unicode's test_format:

"{0.}".format() raises a ValueError (because the format string is invalid) rather than an IndexError (because there is no argument)

"{0[}".format(), likewise.

"{0]}".format() raises a ValueError (because the format string is invalid) rather than a KeyError (because "0]" is taken to be the name of a keyword argument---meaning that the test suite was testing the actual behavior of the implementation rather than the documented behavior).

"{c]}".format(), likewise.

In this patch, "{0[{1}]}".format('abcdef', 4) raises a ValueError rather than a TypeError, because "{1}", being neither a decimalinteger nor an identifier, invalidates the replacement field.

Both patches also add tests for constructions like this:

"{[0]}".format([3]) --> '3'
"{.__class__}".format(3) --> "<type 'int'>"

This conforms with the documentation (and current behavior), since in it arg_name is defined to be optional, but it is not currently covered in test_format, that I could tell, anyway.

----------
Added file: http://bugs.python.org/file22599/strformat-just-identifiers-please.diff

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

From report at bugs.python.org  Thu Jul  7 01:24:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Jul 2011 23:24:12 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1309994652.66.0.417192563002.issue12014@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please stick with "integer" instead of "decimalinteger".   In an effort to make the docs more precise, there is an unintended effect of making them harder to understand.

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

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

From report at bugs.python.org  Thu Jul  7 01:25:15 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 06 Jul 2011 23:25:15 +0000
Subject: [issue12509] test_gdb fails on debug build when builddir != srcdir
In-Reply-To: <1309994715.39.0.391727043164.issue12509@psf.upfronthosting.co.za>
Message-ID: <1309994715.39.0.391727043164.issue12509@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

test_gdb.py fails when builddir != srcdir: the regex tries to match lines like this:
  #0  builtin_id (self=<module at remote 0x7ffff20d3240>, v=()) at ../Python/bltinmodule.c:919

but isn't expecting the "../" before the "Python/bltinmodule.c"

2.7 uses a different regexp, and I don't think it's affected by an analogous problem.

----------
assignee: dmalcolm
components: None
files: fix-test_gdb-regexp.patch
keywords: patch
messages: 139960
nosy: dmalcolm, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: test_gdb fails on debug build when builddir != srcdir
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22600/fix-test_gdb-regexp.patch

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

From report at bugs.python.org  Thu Jul  7 01:26:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Jul 2011 23:26:17 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1309994777.83.0.411224353543.issue12508@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

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

From report at bugs.python.org  Thu Jul  7 01:27:22 2011
From: report at bugs.python.org (Roy Fox)
Date: Wed, 06 Jul 2011 23:27:22 +0000
Subject: [issue12510] IDLE get_the_calltip mishandles raw strings
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>


New submission from Roy Fox <roy.d.fox at gmail.com>:

Hi,

When you type (not copy-paste!) into an IDLE shell a string literal followed by (
you get a calltip.

When the string contains a bad unicode escaping you get an error (see example below), which makes some sense.

But when the string is raw, it isn't treated as such, and you may get the same error, though now it doesn't make any sense.

Non-raw example:

>>> '\xyz'(

>>> *** Internal Error: rpc.py:SocketIO.localcall()

 Object: exec 
 Method: <bound method Executive.get_the_calltip of <idlelib.run.Executive object at 0x021C2910>> 
 Args: ("'\\xyz'",)

Traceback (most recent call last):
  File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "C:\Python32\lib\idlelib\run.py", line 324, in get_the_calltip
    return self.calltip.fetch_tip(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 103, in fetch_tip
    entity = self.get_entity(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 112, in get_entity
    return eval(name, namespace)
  File "<string>", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \xXX escape


Raw example:

>>> r'\xyz'(

>>> *** Internal Error: rpc.py:SocketIO.localcall()

 Object: exec 
 Method: <bound method Executive.get_the_calltip of <idlelib.run.Executive object at 0x021C2910>> 
 Args: ("'\\xyz'",)

Traceback (most recent call last):
  File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
    ret = method(*args, **kwargs)
  File "C:\Python32\lib\idlelib\run.py", line 324, in get_the_calltip
    return self.calltip.fetch_tip(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 103, in fetch_tip
    entity = self.get_entity(name)
  File "C:\Python32\lib\idlelib\CallTips.py", line 112, in get_entity
    return eval(name, namespace)
  File "<string>", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \xXX escape

----------
components: IDLE
messages: 139961
nosy: Roy.Fox
priority: normal
severity: normal
status: open
title: IDLE get_the_calltip mishandles raw strings
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jul  7 02:04:36 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Thu, 07 Jul 2011 00:04:36 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1309997076.7.0.0740362151206.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

undo integer -> decimalinteger in docs

----------
Added file: http://bugs.python.org/file22601/strformat-as-documented.diff

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

From report at bugs.python.org  Thu Jul  7 02:05:01 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Thu, 07 Jul 2011 00:05:01 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1309997101.23.0.293580261144.issue12014@psf.upfronthosting.co.za>


Changes by Ben Wolfson <wolfson at gmail.com>:


Removed file: http://bugs.python.org/file22598/strformat-as-documented.diff

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

From report at bugs.python.org  Thu Jul  7 02:05:28 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Thu, 07 Jul 2011 00:05:28 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1309997128.24.0.271778390628.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

(same as previous)

----------
Added file: http://bugs.python.org/file22602/strformat-just-identifiers-please.diff

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

From report at bugs.python.org  Thu Jul  7 02:05:36 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Thu, 07 Jul 2011 00:05:36 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1309997136.83.0.478637826317.issue12014@psf.upfronthosting.co.za>


Changes by Ben Wolfson <wolfson at gmail.com>:


Removed file: http://bugs.python.org/file22599/strformat-just-identifiers-please.diff

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

From report at bugs.python.org  Thu Jul  7 03:44:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Jul 2011 01:44:03 +0000
Subject: [issue11436] Clarify struct doc for format 's',
	when it is mentioned without numeric prefix
In-Reply-To: <1299522578.2.0.51699411527.issue11436@psf.upfronthosting.co.za>
Message-ID: <1310003043.08.0.711986506428.issue11436@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Those others field types have a standard or system-dependent fixed size and a number is an optional repeat count. Format 's' is always a single field because number prefix for that is special -- a field size.

"For the 's' format character, the count is interpreted as the length of the bytes, not a repeat count like for the other format characters; for example, '10s' means a single 10-byte string, while '10c' means 10 characters. "

I happen to think is could use a few more words of special explanation. Looking again, I think ", which defaults to 1" after the first 'count' above, would be sufficient. We nearly always docucument defaults.

----------

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

From report at bugs.python.org  Thu Jul  7 11:37:17 2011
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 07 Jul 2011 09:37:17 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1310031437.51.0.854052417494.issue10278@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

What's the status of this bug? This is a very useful feature, I've had to use and add bindings to monotonic times for numerous applications. Can it make it into 3.3?

----------

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

From report at bugs.python.org  Thu Jul  7 12:08:07 2011
From: report at bugs.python.org (Saul Spatz)
Date: Thu, 07 Jul 2011 10:08:07 +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: <1310033287.06.0.443491496379.issue8271@psf.upfronthosting.co.za>


Changes by Saul Spatz <saul.spatz at gmail.com>:


----------
nosy: +spatz123

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

From report at bugs.python.org  Thu Jul  7 12:13:10 2011
From: report at bugs.python.org (Andreas Hasenkopf)
Date: Thu, 07 Jul 2011 10:13:10 +0000
Subject: [issue12511] class/instance xyz has no attribute '_abc'
In-Reply-To: <1310033590.5.0.471814241717.issue12511@psf.upfronthosting.co.za>
Message-ID: <1310033590.5.0.471814241717.issue12511@psf.upfronthosting.co.za>


New submission from Andreas Hasenkopf <webmaster at hasenkopf2000.net>:

I'm using 64bit Arch Linux and Python 2.7.2 compiled with GCC 4.6.1.

I have noticed in several ocassions that the interpreter is complaining about

AttributeError: XMLGenerator instance has no attribute '_write' (in case of module xml.sax.saxutils.XMLGenerator)

or

AttributeError: RendererGDK instance has no attribute '_text2path' (in case of matplotlib when trying to use TeX formatting of text)

When I have a look into the corresponding modules I can clearly see method definitions (e.g. def _write(self, text) in line 97 of xml/sax/saxutils.py

I have no clue, why it is happening in some modules, but not in others. If a write my own module containing a class with a _write method it is working fine.
If I write a class derived from xml.sax.saxutils.XMLGenerator and overwrite the _write method it is known to the system, but many of the attributes beginning with an underscore appear still to be unknown...

This is very odd?!

----------
components: XML
messages: 139966
nosy: Andreas.Hasenkopf
priority: normal
severity: normal
status: open
title: class/instance xyz has no attribute '_abc'
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul  7 12:44:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 10:44:13 +0000
Subject: [issue9242] unicodeobject.c: use of uninitialized values
In-Reply-To: <1279013088.42.0.0403163187541.issue9242@psf.upfronthosting.co.za>
Message-ID: <1310035453.5.0.584765842256.issue9242@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/issue9242>
_______________________________________

From report at bugs.python.org  Thu Jul  7 12:44:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 10:44:56 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310035496.36.0.0623267278419.issue5505@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/issue5505>
_______________________________________

From report at bugs.python.org  Thu Jul  7 12:50:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 10:50:01 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1310035801.78.0.438007040732.issue10117@psf.upfronthosting.co.za>


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

> Leaving open to discuss whether anything can/should be done
> for the case when reindent acts as an stdin

sys.stdin.buffer and sys.stdout.buffer should be used with tokenize.detect_encoding(). We may read first stdin and write it into a BytesIO object to be able to rewind after detect_encoding. Something like:

content = sys.stdin.buffer.read()
raw = io.BytesIO(content)
buffer = io.BufferedReader(raw)
encoding, _ = detect_encoding(buffer.readline)
buffer.seek(0)
text = TextIOWrapper(buffer, encoding)
# use text

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

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

From report at bugs.python.org  Thu Jul  7 12:50:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 10:50:55 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1310035855.17.0.719824001337.issue10284@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul  7 12:52:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 10:52:51 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1295450896.02.0.86964827296.issue10945@psf.upfronthosting.co.za>
Message-ID: <1310035971.08.0.859345296489.issue10945@psf.upfronthosting.co.za>


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

Can't you only work with Unicode and avoid the MBCS encoding?

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

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

From report at bugs.python.org  Thu Jul  7 13:00:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 11:00:56 +0000
Subject: [issue10872] Add mode to TextIOWrapper repr
In-Reply-To: <1294564948.19.0.858903256762.issue10872@psf.upfronthosting.co.za>
Message-ID: <1310036456.82.0.577240673089.issue10872@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/issue10872>
_______________________________________

From report at bugs.python.org  Thu Jul  7 13:14:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 11:14:35 +0000
Subject: [issue12512] codecs: StreamWriter issue with stateful codecs after a
	seek
In-Reply-To: <1310037275.84.0.0119141520986.issue12512@psf.upfronthosting.co.za>
Message-ID: <1310037275.84.0.0119141520986.issue12512@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code fails with an AssertionError('###\ufeffdef'):

import codecs
_open = codecs.open
#_open = open
filename = "test"
with _open(filename, 'w', encoding='utf_16') as f:
    f.write('abc')
    pos = f.tell()
with _open(filename, 'w', encoding='utf_16') as f:
    f.seek(pos)
    f.write('def')
    f.seek(0)
    f.write('###')
with _open(filename, 'r', encoding='utf_16') as f:
    content = f.read()
    assert content == '###def', ascii(content)

It is a bug in StreamWriter.seek(): it should update the encoder state to not write a new BOM. It has to be fixed in the StreamWriter class of each stateful codec, or a stateful StreamWriter class should be implemented in the codecs module.

Python supports the following stateful codecs:

 * cp932
 * cp949
 * cp950
 * euc_jis_2004
 * euc_jisx2003
 * euc_jp
 * euc_kr
 * gb18030
 * gbk
 * hz
 * iso2022_jp
 * iso2022_jp_1
 * iso2022_jp_2
 * iso2022_jp_2004
 * iso2022_jp_3
 * iso2022_jp_ext
 * iso2022_kr
 * shift_jis
 * shift_jis_2004
 * shift_jisx0213
 * utf_8_sig
 * utf_16
 * utf_32

This bug has already been fixed in TextIOWrapper: issue #5006.

----------
messages: 139969
nosy: haypo
priority: normal
severity: normal
status: open
title: codecs: StreamWriter issue with stateful codecs after a seek
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  7 13:20:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 11:20:55 +0000
Subject: [issue12512] codecs: StreamWriter issues with stateful codecs after a
	seek or with append mode
In-Reply-To: <1310037275.84.0.0119141520986.issue12512@psf.upfronthosting.co.za>
Message-ID: <1310037655.23.0.74604040049.issue12512@psf.upfronthosting.co.za>


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

There is a similar bug for append mode:

import codecs
_open = codecs.open
#_open = open
filename = "test"
with _open(filename, 'w', encoding='utf_16') as f:
    f.write('abc')
with _open(filename, 'a', encoding='utf_16') as f:
    f.write('def')
with _open(filename, 'r', encoding='utf_16') as f:
    content = f.read()
    assert content == 'abcdef', ascii(content)

This bug has also been fixed by the issue #5006 in the io module.

----------
title: codecs: StreamWriter issue with stateful codecs after a seek -> codecs: StreamWriter issues with stateful codecs after a seek or with append mode

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

From report at bugs.python.org  Thu Jul  7 13:59:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Jul 2011 11:59:40 +0000
Subject: [issue12391] packaging install fails to clean up temp files
In-Reply-To: <1308815016.03.0.685993126745.issue12391@psf.upfronthosting.co.za>
Message-ID: <E1QenF4-0008I8-VG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a4405b799e1b by Vinay Sajip in branch 'default':
Closes #12391: temporary files are now cleaned up.
http://hg.python.org/cpython/rev/a4405b799e1b

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jul  7 14:04:13 2011
From: report at bugs.python.org (Hans Bering)
Date: Thu, 07 Jul 2011 12:04:13 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1310040253.06.0.500267903393.issue10647@psf.upfronthosting.co.za>


Hans Bering <hans.bering at arcor.de> added the comment:

Ok, _now_ I have run into the same problem. I have attached a small script similar to the original entry (but shorter) which will reliably crash with Python 3.1.4 on Windows 7 (64bit) when using a locale with a comma decimal fraction marker (e.g., German). The stacktrace is as follows:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python31\lib\tkinter\__init__.py", line 1400, in __call__
    return self.func(*args)
  File "C:\Python31\lib\tkinter\__init__.py", line 2799, in set
    self.tk.call((self._w, 'set') + args)
_tkinter.TclError: expected floating-point number but got "0,2"

The script runs fine with an English locale. It also runs fine with Python 3.2 on the same machine & Windows & German locale.

The reason seems to be that the Scrollbar lets its self.tk compute fractions which self.tk returns as locale-dependent strings; the Scrollbar runs into problems when converting these strings into floats.

----------
Added file: http://bugs.python.org/file22603/scrollbarCrash1.py

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

From report at bugs.python.org  Thu Jul  7 14:04:21 2011
From: report at bugs.python.org (Hans Bering)
Date: Thu, 07 Jul 2011 12:04:21 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1310040261.89.0.455512406232.issue10647@psf.upfronthosting.co.za>


Changes by Hans Bering <hans.bering at arcor.de>:


Removed file: http://bugs.python.org/file22535/tkinterCrash.py

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

From report at bugs.python.org  Thu Jul  7 14:36:08 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 07 Jul 2011 12:36:08 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310042168.86.0.0786620825713.issue12167@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Attached is a patch that replaces `lib2to3.fixer_Base.BaseFix.set_filename()` during tests. With the patch applied, I don't get any refleaks for packaging.

Another approach would be to simply remove the logging attribute of lib2to3 fixers, as it isn't used anyway.

----------
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file22604/issue12167_patch_2to3.patch

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

From report at bugs.python.org  Thu Jul  7 14:51:32 2011
From: report at bugs.python.org (Ralf Schlatterbeck)
Date: Thu, 07 Jul 2011 12:51:32 +0000
Subject: [issue10945] bdist_wininst depends on MBCS codec,
	unavailable on non-Windows
In-Reply-To: <1310035971.08.0.859345296489.issue10945@psf.upfronthosting.co.za>
Message-ID: <20110707125130.GA28059@runtux.com>


Ralf Schlatterbeck <rsc at runtux.com> added the comment:

On Thu, Jul 07, 2011 at 10:52:51AM +0000, STINNER Victor wrote:
> 
> Can't you only work with Unicode and avoid the MBCS encoding?

I'm trying to build a windows binary package on Linux. This usually
works fine -- as long as the package description doesn't contain
unicode. If it *contains* unicode it will somehow internally use MBCS
encoding.
So if someone fixes windows binary package building on non-windows
platforms to not use MBCS encoding this is fine with me. But maybe the
easier way out here is to include that codec on all platforms.

(and don't tell me I have to install windows for building a windows
binary package :-)

Thanks, Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office at runtux.com
osAlliance member                       email: rsc at osalliance.com

----------

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

From report at bugs.python.org  Thu Jul  7 15:12:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 13:12:47 +0000
Subject: [issue12513] codec.StreamReaderWriter: issues with interlaced
	read-write
In-Reply-To: <1310044367.3.0.915426685652.issue12513@psf.upfronthosting.co.za>
Message-ID: <1310044367.3.0.915426685652.issue12513@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following test fails with an AssertionError('a' != 'b') on the first read.

import codecs

FILENAME = 'test'

with open(FILENAME, 'wb') as f:
    f.write('abcd'.encode('utf-8'))
with codecs.open(FILENAME, 'r+', encoding='utf-8') as f:
    f.write("1")

    pos = f.writer.tell()
    assert pos == 1, "writer pos: %s != 1" % pos
    pos = f.reader.tell()
    assert pos == 1, "reader pos: %s != 1" % pos
    pos = f.stream.tell()
    assert pos == 1, "stream pos: %s != 1" % pos

    # read() must call writer.flush()
    char = f.read(1)
    assert char == 'b', "%r != 'b'" % (char,)
    # write() must rewind the raw stream
    f.write('3')
    tail = f.read()
    assert tail == 'd', "%r != 'd'" % (tail,)
    f.flush()
    with open(FILENAME, 'rb') as f:
        assert f.read() == b'1b3d'

I suppose that readline(), readlines() and __next__() have also issues.

See also issue #12215: similar issue with io.TextIOWrapper.

----------
components: Library (Lib), Unicode
messages: 139975
nosy: haypo
priority: normal
severity: normal
status: open
title: codec.StreamReaderWriter: issues with interlaced read-write
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  7 15:18:26 2011
From: report at bugs.python.org (Andreas Hasenkopf)
Date: Thu, 07 Jul 2011 13:18:26 +0000
Subject: [issue12511] class/instance xyz has no attribute '_abc'
In-Reply-To: <1310033590.5.0.471814241717.issue12511@psf.upfronthosting.co.za>
Message-ID: <1310044706.39.0.819368720429.issue12511@psf.upfronthosting.co.za>


Andreas Hasenkopf <webmaster at hasenkopf2000.net> added the comment:

I'd like to mention that Python 2.6.7 does not show this erroneous behavior. In Python 2.6.7 I can call the _write method of xml.sax.saxutils.XMLGenerator...

Is this a bug or a feature in 2.7??

----------
components:  -XML

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

From report at bugs.python.org  Thu Jul  7 15:24:20 2011
From: report at bugs.python.org (Andreas Hasenkopf)
Date: Thu, 07 Jul 2011 13:24:20 +0000
Subject: [issue12511] class/instance xyz has no attribute '_abc'
In-Reply-To: <1310033590.5.0.471814241717.issue12511@psf.upfronthosting.co.za>
Message-ID: <1310045060.11.0.111295095262.issue12511@psf.upfronthosting.co.za>


Andreas Hasenkopf <webmaster at hasenkopf2000.net> added the comment:

The problem appeared to be the package from the Arch Linux repo.
Compiling the source codes myselfes gave me a Python interpreter not showing this bug...

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

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

From report at bugs.python.org  Thu Jul  7 15:28:56 2011
From: report at bugs.python.org (bjorn lofdahl)
Date: Thu, 07 Jul 2011 13:28:56 +0000
Subject: [issue12506] NIS module cant handle multiple NIS map entries for the
	same GID
In-Reply-To: <1309956537.93.0.737876319543.issue12506@psf.upfronthosting.co.za>
Message-ID: <1310045336.89.0.625361658942.issue12506@psf.upfronthosting.co.za>


Changes by bjorn lofdahl <bjorn.lofdahl at gmail.com>:


----------
versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4 -Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Jul  7 15:29:14 2011
From: report at bugs.python.org (bjorn lofdahl)
Date: Thu, 07 Jul 2011 13:29:14 +0000
Subject: [issue12506] NIS module cant handle multiple NIS map entries for the
	same GID
In-Reply-To: <1309956537.93.0.737876319543.issue12506@psf.upfronthosting.co.za>
Message-ID: <1310045354.19.0.298255779699.issue12506@psf.upfronthosting.co.za>


Changes by bjorn lofdahl <bjorn.lofdahl at gmail.com>:


----------
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Jul  7 16:40:39 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Jul 2011 14:40:39 +0000
Subject: [issue12511] class/instance xyz has no attribute '_abc'
In-Reply-To: <1310033590.5.0.471814241717.issue12511@psf.upfronthosting.co.za>
Message-ID: <1310049639.61.0.783739667895.issue12511@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution: accepted -> invalid

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

From report at bugs.python.org  Thu Jul  7 16:58:53 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 07 Jul 2011 14:58:53 +0000
Subject: [issue12514] timeit disables garbage collection if timed code raises
	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>


New submission from Gareth Rees <gdr at garethrees.org>:

If you call timeit.timeit and the timed code raises an exception, then garbage collection is disabled. I have verified this in Python 2.7 and 3.2. Here's an interaction with Python 3.2:

    Python 3.2 (r32:88445, Jul  7 2011, 15:52:49) 
    [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import timeit, gc
    >>> gc.isenabled()
    True
    >>> timeit.timeit('raise Exception')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/timeit.py", line 228, in timeit
        return Timer(stmt, setup, timer).timeit(number)
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/timeit.py", line 194, in timeit
        timing = self.inner(it, self.timer)
      File "<timeit-src>", line 6, in inner
    Exception
    >>> gc.isenabled()
    False

The problem is with the following code in Lib/timeit.py (lines 192?196):

    gcold = gc.isenabled()
    gc.disable()
    timing = self.inner(it, self.timer)
    if gcold:
        gc.enable()

This should be changed to something like this:

    gcold = gc.isenabled()
    gc.disable()
    try:
        timing = self.inner(it, self.timer)
    finally:
        if gcold:
            gc.enable()

----------
components: Library (Lib)
messages: 139978
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: timeit disables garbage collection if timed code raises an exception
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Jul  7 17:13:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Jul 2011 15:13:21 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1310051601.33.0.793215053291.issue10403@psf.upfronthosting.co.za>


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

Senthil, I?m not sure you read Alexander?s reply on Rietveld before committing.

----------

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

From report at bugs.python.org  Thu Jul  7 17:58:02 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 07 Jul 2011 15:58:02 +0000
Subject: [issue12514] timeit disables garbage collection if timed code raises
	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <1310054282.87.0.969489944712.issue12514@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file22605/issue12514.patch

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

From report at bugs.python.org  Thu Jul  7 18:32:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Jul 2011 16:32:19 +0000
Subject: [issue12514] timeit disables garbage collection if timed code raises
	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <1310056339.68.0.185457216552.issue12514@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Thu Jul  7 18:33:45 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Jul 2011 16:33:45 +0000
Subject: [issue12514] timeit disables garbage collection if timed code raises
	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <1310056425.46.0.802420901985.issue12514@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you.  The patch looks correct.  I will apply it as soon as I get a chance.

----------

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

From report at bugs.python.org  Thu Jul  7 18:37:22 2011
From: report at bugs.python.org (xavierd)
Date: Thu, 07 Jul 2011 16:37:22 +0000
Subject: [issue12515] The email package modifies the message structure (when
	the parsed email is invalid)
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>


New submission from xavierd <xdelannoy at cloudmark.com>:

the function 'email.message_from_file' modifies the message structure when the parsed is invalid (for example, when a closed boudary is missing). The attribute defects is also empty

In the attachment (sample.tgz) you will find:
   - orig.eml : an email with an invalid structure The boundary
"000101020201080900040301" isn't closed
   - after_parsing.eml: same email after calling email.message_from_file()
The boundary is now closed. And the defects attribute is empty
   - test.py: python script to reproduce.

----------
components: None
files: sample.tgz
messages: 139982
nosy: r.david.murray, xavierd
priority: normal
severity: normal
status: open
title: The email package modifies the message structure (when the parsed email is invalid)
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file22606/sample.tgz

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

From report at bugs.python.org  Thu Jul  7 19:39:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Jul 2011 17:39:30 +0000
Subject: [issue12504] packaging: fix uninstall and stop skipping its tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1310060370.6.0.854735568348.issue12504@psf.upfronthosting.co.za>


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

Thanks for that!  I agree that it?s a fake optimization to work with generators instead of lists when the list is small or when we depend on other resources like file handles.  There are a few methods we could change in the database module.

The patch looks good, except that I wouldn?t move code to a nested function, but just change the ?yield spam? line to ?results.append(spam)?.

In our message, is the test log showing failure something you got before making changes or after?  IOW, does the patch fixes the bug?

----------
assignee: tarek -> eric.araujo
stage:  -> patch review
title: Uninstall has disabled windows tests -> packaging: fix uninstall and stop skipping its tests

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

From report at bugs.python.org  Thu Jul  7 19:43:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Jul 2011 17:43:00 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310060580.18.0.803296795089.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks a lot for the diagnosis.

To fix it, I don?t find the monkey-patching approach very good, I?d prefer properly using the logging API to remove handlers upon cleanup.  Would you like to look into that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jul  7 19:46:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Jul 2011 17:46:15 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1310060580.18.0.803296795089.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310060723.30177.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To fix it, I don?t find the monkey-patching approach very good, I?d
> prefer properly using the logging API to remove handlers upon cleanup.

I don't think such stuff exists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jul  7 19:56:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Jul 2011 17:56:25 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310061385.59.0.552294641467.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See http://hg.python.org/cpython/file/tip/Lib/packaging/tests/support.py#l81

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jul  7 19:57:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Jul 2011 17:57:43 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1310061385.59.0.552294641467.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310061410.30177.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> See http://hg.python.org/cpython/file/tip/Lib/packaging/tests/support.py#l81

AFAIU, the problem is that 2to3 creates a whole new logger for each
different file. So it's not about cleaning the handlers, but cleaning up
the loggers as well. And logging (deliberately, according to Vinay)
doesn't provide any API to destroy loggers (they are de facto eternal).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jul  7 19:59:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Jul 2011 17:59:52 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310061592.15.0.969970459752.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for clarifying, I had misread.  IMO, using one logger per file is a lib2to3 bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Thu Jul  7 20:05:14 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Thu, 07 Jul 2011 18:05:14 +0000
Subject: [issue12504] packaging: fix uninstall and stop skipping its tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1310061914.59.0.90108006784.issue12504@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

The output in my initial message is the output of the tests with them enabled but pre database.py patch. Once the patch is applied all packaging tests that run on my system pass.

I was 50/50 on whether or not to use the internal function and I just sort of ended up with it. I had started out writing some more complex map/list comprehension stuff and the function made sense at the time.

Regarding the use of yield, at least one of the other functions that uses the _get_records function yields the result of _get_records. I figured those could be altered to just return the list directly but I decided to opt for the path of least modification prior to getting input.

If you think it is a good idea I will modify the patch to remove the unnecessary yields and insert the nested function code directly in _get_records instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12504>
_______________________________________

From report at bugs.python.org  Thu Jul  7 20:06:15 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Thu, 07 Jul 2011 18:06:15 +0000
Subject: [issue12504] packaging: fix uninstall and stop skipping its tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1310061975.8.0.715688874313.issue12504@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

Oh and thank you very much for your input. My apologies for the initial 9 e-mail spam when I created the issue, I bumbled the remote HG repository patch generation :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12504>
_______________________________________

From report at bugs.python.org  Thu Jul  7 20:48:23 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 07 Jul 2011 18:48:23 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1310064503.49.0.608584515477.issue12183@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Shouldn't at least shutil.copytree() use lutimes in Python 3.3 to copy symlink metadata if symlinks=True?

----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12183>
_______________________________________

From report at bugs.python.org  Thu Jul  7 20:59:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 07 Jul 2011 18:59:14 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1310065154.32.0.916610366448.issue12183@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch that documents the behavior of copy2() and copytree() for symlinks.

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file22607/copy2_copytree_symlinks_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12183>
_______________________________________

From report at bugs.python.org  Thu Jul  7 21:00:00 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 07 Jul 2011 19:00:00 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1310065200.94.0.396375595268.issue12183@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12183>
_______________________________________

From report at bugs.python.org  Thu Jul  7 21:56:46 2011
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 07 Jul 2011 19:56:46 +0000
Subject: [issue12516] imghdr.what should take one argument
In-Reply-To: <1310068606.02.0.0739859897948.issue12516@psf.upfronthosting.co.za>
Message-ID: <1310068606.02.0.0739859897948.issue12516@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

Currently imghdr.what() accepts two parameters. The first is a file or filename and the second is a byte stream. If the second is not None, the first is ignored. This is clunky. It would be simpler to accept just one argument, which can be either an open file or a byte stream.

I have attached a patch which implements this one argument approach as private function imghdr_what(). I have left imghdr.what() as a wrapper around this new function for backwards compatibility (in the hopes that it will eventually be replaced).

In addition, there did not seem to be any tests for the imghdr module, so I added a few simple tests.

----------
components: Library (Lib)
files: imghdr.patch
keywords: patch
messages: 139993
nosy: jfinkels
priority: normal
severity: normal
status: open
title: imghdr.what should take one argument
type: feature request
versions: Python 3.4
Added file: http://bugs.python.org/file22608/imghdr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12516>
_______________________________________

From report at bugs.python.org  Thu Jul  7 23:08:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 21:08:37 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310072917.45.0.250849362325.issue5505@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I am still able to reproduce the problem with Python 3.2.1RC1 (64 bits) on Windows Seven, but not on Python 3.3 (alpha) compiled myself (using Visual C++ Express 2008).

I don't know if something changed in Python 3.3, or it is related to how I compiled Python? I don't think that it is related to issue #12016 because Python 3.2.1RC1 contains the fix for #12016.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Thu Jul  7 23:37:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 21:37:34 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310074654.04.0.570155390003.issue5505@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I don't know if something changed in Python 3.3, or ...

Yes, something changed in Python 3.3. I fixed this issue "by mistake" :-) The fix is the following commit:

New changeset 3c7792ec4547 by Victor Stinner in branch 'default':
Issue #12175: BufferedReader.read(-1) now calls raw.readall() if available.
http://hg.python.org/cpython/rev/3c7792ec4547

It is a bug in BufferedReader, a bug or an unexpected behaviour. Before this commit (e.g. in Python 3.2.0), BufferedReader.read(-1) calls raw.read() two times for this issue: the first call returns an non empty string (the string until the first ^Z), the second call returns an empty string (the string until the second ^Z). BufferedReader.read(-1) loop ends with raw.read() returns an empty string.

You can workaround this issue by calling sys.stdin.buffer.raw.readall() or sys.stdin.buffer.raw.read(-1).

I chose to not port my BufferedRead.read(-1) fix (call raw.readall() if available) in Python 3.2 because it changes the behaviour, and I don't want to do that in a minor release.

Is anyone in favor of changing the behaviour of BufferedRead.read(-1) in a minor release (next 2.7.3 and 3.2.2)? Or can I close the issue (the bug is already fixed in Python 3.3)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Fri Jul  8 00:07:45 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 07 Jul 2011 22:07:45 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1310076465.94.0.672636389451.issue10883@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Updated patch with fixed refcounting mechanism. Also fixes clear_cache() in
CacheFTPWrapper to leave the cache in a consistent state for subsequent use.

----------
Added file: http://bugs.python.org/file22609/issue10883-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Fri Jul  8 00:54:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 22:54:10 +0000
Subject: [issue12517] Large file support on Windows: sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

FileIO.readall() and _parse_off_t() help of the posix module use the off_t type. This type is only 32 bits long and so don't support files bigger than 4 GB (or maybe just 2 GB?). The Py_off_t type should be used instead.

----------
components: Windows
messages: 139997
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: Large file support on Windows: sizeof(off_t) is 32 bits
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12517>
_______________________________________

From report at bugs.python.org  Fri Jul  8 00:58:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 22:58:11 +0000
Subject: [issue12517] Large file support on Windows: sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: <1310079491.14.0.470316953654.issue12517@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

fileio_py_off_t.patch: Fix for FileIO.readall().

The consequence of the integer overflow in new_buffersize() looks to be that the buffer can be too small in some cases (and so readall() can be very slow?).

----------
keywords: +patch
Added file: http://bugs.python.org/file22610/fileio_py_off_t.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12517>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:03:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 23:03:02 +0000
Subject: [issue12517] Large file support on Windows: sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: <1310079782.72.0.348374391802.issue12517@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_parse_off_t() is used by the following functions:
- lockf
- pread, pwrite
- sendfile
- truncate, ftruncate
- posix_advice, posix_fallocate

Windows has none of these functions. _parse_off_t() may be surrounded by #ifndef MS_WINDOWS with a comment explaining that Py_off_t should be used on Windows to support large files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12517>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:10:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Jul 2011 23:10:40 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <E1QexiR-0001I2-Fm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 43fd627cc060 by Victor Stinner in branch 'default':
Issue #9566: cast unsigned int to Py_ssize_t in md5 and sha1 modules
http://hg.python.org/cpython/rev/43fd627cc060

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9566>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:25:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 23:25:02 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1310081102.92.0.52477352371.issue10117@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

reindent_coding.py: patch fixing reindent.py when using pipes (stdin and stdout).

----------
versions: +Python 3.3
Added file: http://bugs.python.org/file22611/reindent_coding.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:31:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Jul 2011 23:31:42 +0000
Subject: [issue12178] csv writer doesn't escape escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1310081502.8.0.315090776403.issue12178@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  The tests look good at first glance.  I can?t comment on the C code, I don?t know C.  Hopefully someone will do it, otherwise if you don?t get feedback in say four weeks you can ask for a review on python-dev.

----------
keywords: +needs review
stage:  -> patch review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12178>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:43:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Jul 2011 23:43:16 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1310082196.86.0.305199581397.issue10117@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is a lot more code than what I?d have expected.

What is your opinion on my previous message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:45:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Jul 2011 23:45:24 +0000
Subject: [issue12016] Wrong behavior for '\xff\n'.decode('gb2312', 'ignore')
In-Reply-To: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>
Message-ID: <E1QeyG3-0003Ov-1N@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 16cbd84de848 by Victor Stinner in branch 'default':
Issue #12016: Multibyte CJK decoders now resynchronize faster
http://hg.python.org/cpython/rev/16cbd84de848

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:47:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 23:47:28 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1310082448.44.0.461874132365.issue10117@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> When working as a filter, reindent should use sys.{stdin,stdout}.encoding
> (defaulting to sys.getdefaultencoding()) for reading and writing,
> respectively.

It just doesn't work: you cannot read a ISO-8859-1 file from UTF-8 (if your locale encoding is UTF-8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Jul  8 01:52:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Jul 2011 23:52:17 +0000
Subject: [issue12016] Wrong behavior for '\xff\n'.decode('gb2312', 'ignore')
In-Reply-To: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>
Message-ID: <1310082737.33.0.962906376678.issue12016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Because I consider this issue as a bug, I would like
> to apply this patch to 2.7, 3.2 and 3.3.

It is maybe a bug but it is also an important change on Python behaviour, so finally I prefer to only change (fix) Python 3.3.

Thanks for reporting the bug zy (cdqzzy). Tell me if it now behaves as you expected.

I'm closing this issue because the initial issue is now fixed.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Fri Jul  8 02:08:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jul 2011 00:08:04 +0000
Subject: [issue12501] callable(): remove/amend the deprecation warning in
	Python 2.7
In-Reply-To: <1309865750.34.0.541248470896.issue12501@psf.upfronthosting.co.za>
Message-ID: <E1Qeyby-0004rb-SW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1f814faaf54d by Victor Stinner in branch '2.7':
Close #12501: Adjust callable() warning: callable() is only not supported in
http://hg.python.org/cpython/rev/1f814faaf54d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12501>
_______________________________________

From report at bugs.python.org  Fri Jul  8 02:27:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jul 2011 00:27:21 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <E1Qeyub-00062U-94@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1ac21a715c5d by Victor Stinner in branch '2.7':
Issue #12423: Fix os.abort() documentation
http://hg.python.org/cpython/rev/1ac21a715c5d

New changeset 4e83d8f6d496 by Victor Stinner in branch '3.2':
Issue #12423: Fix os.abort() documentation
http://hg.python.org/cpython/rev/4e83d8f6d496

New changeset e3c115ba8dc0 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12423: Fix os.abort() documentation
http://hg.python.org/cpython/rev/e3c115ba8dc0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Fri Jul  8 02:28:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Jul 2011 00:28:05 +0000
Subject: [issue12423] signal handler doesn't handle SIGABRT from os.abort
In-Reply-To: <1309197130.0.0.320444785748.issue12423@psf.upfronthosting.co.za>
Message-ID: <1310084885.2.0.856378881322.issue12423@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here's my proposed patch for the documentation, against
> the head of the 2.7 branch.

Thanks, I applied your pach to 2.7, 3.2 and 3.3 doc.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12423>
_______________________________________

From report at bugs.python.org  Fri Jul  8 02:36:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Jul 2011 00:36:20 +0000
Subject: [issue12429] test_io.check_interrupted_write() sporadic failures on
	FreeBSD 6 on Python 2.7/3.2
In-Reply-To: <1309260227.84.0.740113314895.issue12429@psf.upfronthosting.co.za>
Message-ID: <1310085380.08.0.750903728098.issue12429@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12429>
_______________________________________

From report at bugs.python.org  Fri Jul  8 02:36:49 2011
From: report at bugs.python.org (py.user)
Date: Fri, 08 Jul 2011 00:36:49 +0000
Subject: [issue12518] In string.Template it's impossible to transform
	delimiter in the derived class
In-Reply-To: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>
Message-ID: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> import string
>>> class MyTemplate(string.Template):
...   delimiter = '.'
... 
>>> MyTemplate.delimiter = 'x'
>>> mt = MyTemplate('.field xfield')
>>> mt.substitute(field=None)
'None xfield'
>>> mt.delimiter
'x'
>>>


If I want to change the pattern string by any delimiter, I should create a new class for every delimiter

I would change the delimiter either in the object or in the class at any time

----------
components: Library (Lib)
messages: 140010
nosy: py.user
priority: normal
severity: normal
status: open
title: In string.Template it's impossible to transform delimiter in the derived class
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12518>
_______________________________________

From report at bugs.python.org  Fri Jul  8 02:46:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Jul 2011 00:46:03 +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: <1310085963.49.0.877400734702.issue11230@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11230>
_______________________________________

From report at bugs.python.org  Fri Jul  8 03:09:10 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Fri, 08 Jul 2011 01:09:10 +0000
Subject: [issue12504] packaging: fix uninstall and stop skipping its tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1310087350.51.0.225143882488.issue12504@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

I have made the change you suggested, creating a new list and simply amending to minimize the diff. This new patch has been attached.

I looked through the rest of database.py and did not see any other generators that appeared to erroneously hold a file handle open. If you are able to identify one that actually is a problem I would be happy to change it.

In addition there is one generator function (list_distinfo_files) which feeds off of the generator I have changed but I didn't see a need to alter them as they work fine as generators.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12504>
_______________________________________

From report at bugs.python.org  Fri Jul  8 03:09:39 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Fri, 08 Jul 2011 01:09:39 +0000
Subject: [issue12504] packaging: fix uninstall and stop skipping its tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1310087379.97.0.0607656006347.issue12504@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file22612/6e15ba060803.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12504>
_______________________________________

From report at bugs.python.org  Fri Jul  8 03:16:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Jul 2011 01:16:06 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1310087766.43.0.677817325049.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@neologix: I don't understand why do you want to hurry, this issue will not be fixed in the next release (3.2.1, it's too late), and I don't think that the next release (3.3? or is it something before?) will come before few months.

--

I don't think that replacing "linux3" by "linux" for sys.platform does change anything. I agree with neologix:

> Any application relying on sys.platform == 'linux2' is already broken.

Even if we change sys.platform in Python 2.7.3, 3.2.2 and/or 3.3, I bet that some Linux distro will bundle older versions with Linux 3. It means that we will have "linux2", "linux3", "linux". It is just worse.

--

I propose to just patch the code checking for linux2 where it is inappropriate. I attached linux3.patch: patch for Python 3.2 fixing mention of linux2. It replaces sys.platform == 'linux2' by sys.platform in ('linux2', 'linux3'), os.uname()[0] == 'Linux' or platform.system() == 'Linux', depending on the context. In setup.py, I used os.uname()[0] to avoid bootstrap issues, but it is maybe possible to use platform.system() there.

--

@loewis: What is the code responsable to use/load Lib/plat-* modules?

Can we use a symlink from plat-linux2 to plat-linux3? Or should we copy the whole directory?

--

@lemburg: What will be the value of sys.system on Cygwin? "windows" or "cygwin"? It looks like sys.platform is "cygwin" if Python was compiled using Cygwin, "win32" if Python was compiled using Visual Studio. sys.system is maybe redundant with platform.system() (except that platform requires to call os.uname, but only once).

@lemburg: sys.system_info looks to be redundant with the platform module.

----------
keywords: +patch
Added file: http://bugs.python.org/file22613/linux3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jul  8 03:17:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Jul 2011 01:17:00 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1310087820.91.0.654237306025.issue12181@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@neologix: New try. Why did you remove your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri Jul  8 03:33:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Jul 2011 01:33:43 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1310088823.98.0.591500132424.issue1195571@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Sorry, the documentation in the patch is wrong

Can you update your patch please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195571>
_______________________________________

From report at bugs.python.org  Fri Jul  8 09:06:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 08 Jul 2011 07:06:34 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1310087820.91.0.654237306025.issue12181@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3XjqunSWQomOjyGth2d=kLYtKtSsbskG4WrFiRPvmiwQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> @neologix: New try. Why did you remove your patch?
>

Sorry, I completely forgot about this issue.
Because it was incorrect (it would have fixed the SIGBUS, but would
have produced incorrect results).
IIRC, the problem is that those members are used in several places, so
it requires a little bit more work to produce a clean patch.
I'll try to provide a new one in a couple days, but since I don't have
any OpenBSD box, I won't be able to test it myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri Jul  8 09:10:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 08 Jul 2011 07:10:25 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309894308.1.0.33597003372.issue12502@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0-qO9r6n5pBxvDC3ZkYaeVNc-BONJZ5_KLP3mRk9XsWg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Looks good, the patch seems to fix the problem.

Alright.
Giampaolo, do you agree?
Also, I noticed that test_asyncore currently only tests AF_INET sockets.
I'm working a patch to add AF_UNIX (and maybe AF_INET6) tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Fri Jul  8 09:17:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 08 Jul 2011 07:17:46 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1310087766.43.0.677817325049.issue12326@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1UoADUn2NsSO+w3m=1MuT2E8tkQhVDm1Uie9i_orhzKA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> @neologix: I don't understand why do you want to hurry, this issue will not be fixed in the next release (3.2.1, it's too late), and I don't think that the next release (3.3? or is it something before?) will come before few months.
>

Well, I'm not familiar (yet :-) with the release cycle, but I was
concerned with the upcoming Linux 3.0 release (probably a matter of
weeks now).

But if we can't reach a consensus here, we should maybe move this
discussion to the mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jul  8 09:26:15 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 08 Jul 2011 07:26:15 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1310109975.5.0.581294069.issue12502@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Sorry for delay. Yes, patch looks ok to me and some tests for AF_UNIX sockets would definitively be welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Fri Jul  8 11:12:34 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 08 Jul 2011 09:12:34 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1310116354.95.0.0121583457735.issue11969@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri Jul  8 11:46:59 2011
From: report at bugs.python.org (Ben)
Date: Fri, 08 Jul 2011 09:46:59 +0000
Subject: [issue1982] Feature: extend strftime to accept milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1310118419.52.0.374311123046.issue1982@psf.upfronthosting.co.za>


Ben <magicbadger at gmail.com> added the comment:

Sorry to chime in on an old issue. Whilst it is good to have the ability to format the string up to microsecond precision, it would be better to be able to control the precision used.

For instance, the ISO8601 specification states that there is no strictly defined precision to be used, and that any such precision should be agreed between parties exchanging ISO8601 datetimes.

Would it be possible to state the precision when formatting ISO8601 datetimes - e.g. %3f to only print up to millisecond precision? presumable %f would keep the original functionality of printing right up to the microseconds.

----------
nosy: +magicbadger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1982>
_______________________________________

From report at bugs.python.org  Fri Jul  8 13:19:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 11:19:16 +0000
Subject: [issue12504] packaging: fix uninstall and stop skipping its tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1310123956.13.0.293905620456.issue12504@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Excellent!  I will apply this.

> I looked through the rest of database.py and did not see any other
> generators that appeared to erroneously hold a file handle open.
Me neither.  Thanks for checking.

> In addition there is one generator function (list_distinfo_files)
> which feeds off of the generator I have changed but I didn't see a
> need to alter them as they work fine as generators.
I think using a generator can save some memory, if the underlying list is huge, but the important thing here is that all functions with a similar name (list_*) behave in a consistent way, i.e. returning lists or generators but not a mix.

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12504>
_______________________________________

From report at bugs.python.org  Fri Jul  8 13:19:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 11:19:45 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1310123985.37.0.353655344326.issue10117@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Even with PYTHONIOENCODING?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Jul  8 13:24:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 11:24:51 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310124291.05.0.0759123632022.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22614/b1b9da3b3d20.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Fri Jul  8 13:38:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 11:38:10 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1310125090.05.0.40593876453.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I forgot one thing: setuptools? egg_info command does write a list of
> paths, so we can look at how it solved the problem with the RECORD and
> RESOURCES files.

I was wrong: I just checked the output of egg_info, and it does not generate files with paths.

So, what do we do?
1) don?t generate RECORD at all ? invalid PEP 376
2) generate RECORD with paths to the files in the build dir
3) other?
4) don?t add a build_distinfo command, just run install_distinfo to the build dir from the test and develop commands

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Fri Jul  8 13:39:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 11:39:13 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310125153.47.0.80414587943.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know if you?ve seen the review I made (there is a bug with user names on the code review site, sometimes mail does not get sent).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Fri Jul  8 13:58:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 11:58:27 +0000
Subject: [issue11512] adding test suite for cgitb
In-Reply-To: <1300143894.4.0.405606166364.issue11512@psf.upfronthosting.co.za>
Message-ID: <1310126307.53.0.774034789573.issue11512@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not sure this is related, but test_robotparser has started failing on one of the buildbots after this change:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2070

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11512>
_______________________________________

From report at bugs.python.org  Fri Jul  8 15:53:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 13:53:46 +0000
Subject: [issue12519] Call next version 3.3.0
In-Reply-To: <1310133226.52.0.80498205219.issue12519@psf.upfronthosting.co.za>
Message-ID: <1310133226.52.0.80498205219.issue12519@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

As discussed and agreed shortly before the 3.2 release, it?d be best to call the first 3.3 release 3.3.0.

----------
assignee: georg.brandl
messages: 140025
nosy: eric.araujo, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: Call next version 3.3.0
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12519>
_______________________________________

From report at bugs.python.org  Fri Jul  8 15:55:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 13:55:38 +0000
Subject: [issue12503] "with" statement error message is more confusing in Py2.7
In-Reply-To: <1309924683.37.0.310972531328.issue12503@psf.upfronthosting.co.za>
Message-ID: <1310133338.28.0.00226618611148.issue12503@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could AttributeError be improved to say something like this:

AttributeError: type 'type' has no attribute '__enter__'

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12503>
_______________________________________

From report at bugs.python.org  Fri Jul  8 15:56:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 13:56:29 +0000
Subject: [issue12515] email modifies the message structure when the parsed
	email is invalid
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1310133389.37.0.941613990814.issue12515@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> r.david.murray
components: +Library (Lib) -None
stage:  -> needs patch
title: The email package modifies the message structure (when the parsed email is invalid) -> email modifies the message structure when the parsed email is invalid
type:  -> behavior
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12515>
_______________________________________

From report at bugs.python.org  Fri Jul  8 16:01:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 14:01:50 +0000
Subject: [issue12277] Missing comma in os.walk docs
In-Reply-To: <1307439951.32.0.810805209718.issue12277@psf.upfronthosting.co.za>
Message-ID: <1310133710.14.0.565941399766.issue12277@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?pending? does not mean ?soon to be fixed?, but ?soon to be closed if nobody reacts?.  In the future, we may have auto-closing of pending bugs.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12277>
_______________________________________

From report at bugs.python.org  Fri Jul  8 16:28:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jul 2011 14:28:31 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <E1QfC2f-0000jj-KY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c2785ed52ed4 by ?ric Araujo in branch 'default':
Factor out code used by packaging commands for HTTP requests (#12169).
http://hg.python.org/cpython/rev/c2785ed52ed4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Fri Jul  8 16:28:49 2011
From: report at bugs.python.org (Robbie Clemons)
Date: Fri, 08 Jul 2011 14:28:49 +0000
Subject: [issue11512] adding test suite for cgitb
In-Reply-To: <1310126307.53.0.774034789573.issue11512@psf.upfronthosting.co.za>
Message-ID: <CAEDCBpeE9RynbwUCCvYLOu4ctenYxieMGJiGY7UwHF0PA9VcsQ@mail.gmail.com>


Robbie Clemons <robclemons at gmail.com> added the comment:

Pretty sure it has nothing to do with the new cgitb test.  Apparently
testPasswordProtectedSite (test.test_robotparser.NetworkTestCase) uses
website http://mueblesmoraleda.com to run it's test and that site is
currently down.

On Fri, Jul 8, 2011 at 7:58 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Not sure this is related, but test_robotparser has started failing on one of the buildbots after this change:
> http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2070
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11512>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11512>
_______________________________________

From report at bugs.python.org  Fri Jul  8 16:34:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 14:34:26 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
	upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1310135666.8.0.558828012016.issue12169@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I added a few blank lines, changed the error message when boundary is not bytes, moved test_encode_multipart to test_util.py and committed.

Thanks again!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Fri Jul  8 16:37:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 14:37:20 +0000
Subject: [issue4672] Distutils SWIG support blocks use of SWIG -outdir option
In-Reply-To: <1229379752.29.0.666537313596.issue4672@psf.upfronthosting.co.za>
Message-ID: <1310135840.83.0.778067651957.issue4672@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Lists are used because that?s what the UNIX exec call accepts, or the constructor of subprocess.Popen.

About using %r in error messages, see also #11599.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4672>
_______________________________________

From report at bugs.python.org  Fri Jul  8 16:50:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 14:50:14 +0000
Subject: [issue11352] Update cgi module doc
In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>
Message-ID: <1310136614.31.0.0433699516845.issue11352@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review, patch
nosy: +amaury.forgeotdarc, andyharrington, erob, flox, gagenellina, haypo, oopos, pebbe, r.david.murray, tcourbon, tobias, v+python
priority: normal -> high
stage:  -> patch review
title: Bug in cgi module doc -> Update cgi module doc
type: behavior -> 
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11352>
_______________________________________

From report at bugs.python.org  Fri Jul  8 17:22:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jul 2011 15:22:40 +0000
Subject: [issue12504] packaging: fix uninstall and stop skipping its tests
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <E1QfCt5-0005nO-6R@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2b9a0a091566 by ?ric Araujo in branch 'default':
Close file handles in a timely manner in packaging.database (#12504).
http://hg.python.org/cpython/rev/2b9a0a091566

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12504>
_______________________________________

From report at bugs.python.org  Fri Jul  8 17:23:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jul 2011 15:23:58 +0000
Subject: [issue12504] packaging: fix database to stop skipping uninstall tests
	on win32
In-Reply-To: <1309926881.7.0.734520391359.issue12504@psf.upfronthosting.co.za>
Message-ID: <1310138638.94.0.802129360293.issue12504@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Edited a bit and committed.  Thanks again!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
title: packaging: fix uninstall and stop skipping its tests -> packaging: fix database to stop skipping uninstall tests on win32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12504>
_______________________________________

From report at bugs.python.org  Fri Jul  8 17:52:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Jul 2011 15:52:46 +0000
Subject: [issue12519] Call next version 3.3.0
In-Reply-To: <1310133226.52.0.80498205219.issue12519@psf.upfronthosting.co.za>
Message-ID: <1310140366.09.0.95970432558.issue12519@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/issue12519>
_______________________________________

From report at bugs.python.org  Fri Jul  8 18:20:21 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Jul 2011 16:20:21 +0000
Subject: [issue12516] imghdr.what should take one argument
In-Reply-To: <1310068606.02.0.0739859897948.issue12516@psf.upfronthosting.co.za>
Message-ID: <1310142021.14.0.0917891583129.issue12516@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

This seems like a change suitable for 3.3

----------
nosy: +SilentGhost
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12516>
_______________________________________

From report at bugs.python.org  Fri Jul  8 18:50:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jul 2011 16:50:23 +0000
Subject: [issue12440] test_ssl.test_options() failure on Snow Leopard: can't
	clear options before OpenSSL 0.9.8m
In-Reply-To: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>
Message-ID: <E1QfEFs-0004z7-RK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 52ed0c6bb461 by Antoine Pitrou in branch '3.2':
Issue #12440: When testing whether some bits in SSLContext.options can be
http://hg.python.org/cpython/rev/52ed0c6bb461

New changeset 4120cd8a86f4 by Antoine Pitrou in branch 'default':
Issue #12440: When testing whether some bits in SSLContext.options can be
http://hg.python.org/cpython/rev/4120cd8a86f4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12440>
_______________________________________

From report at bugs.python.org  Fri Jul  8 18:51:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 16:51:14 +0000
Subject: [issue12440] test_ssl.test_options() failure on Snow Leopard: can't
	clear options before OpenSSL 0.9.8m
In-Reply-To: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>
Message-ID: <1310143874.17.0.550802604223.issue12440@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now.

----------
assignee: janssen -> 
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12440>
_______________________________________

From report at bugs.python.org  Fri Jul  8 18:52:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 16:52:11 +0000
Subject: [issue12440] test_ssl.test_options() failure on Snow Leopard: can't
	clear options before OpenSSL 0.9.8m
In-Reply-To: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>
Message-ID: <1310143931.35.0.0600628797019.issue12440@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That said, we will probably need to supply our own libssl for Python
> installers in the future as there are rumors that Apple has hinted it
> may no longer supply openssl in the future.

What about their own Python? Will it come without an ssl module?

----------
assignee:  -> janssen
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12440>
_______________________________________

From report at bugs.python.org  Fri Jul  8 18:52:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 16:52:25 +0000
Subject: [issue12440] test_ssl.test_options() failure on Snow Leopard: can't
	clear options before OpenSSL 0.9.8m
In-Reply-To: <1309342379.37.0.935876078434.issue12440@psf.upfronthosting.co.za>
Message-ID: <1310143945.33.0.892303564269.issue12440@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12440>
_______________________________________

From report at bugs.python.org  Fri Jul  8 19:49:51 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 08 Jul 2011 17:49:51 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1310147391.29.0.08520240267.issue12486@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12486>
_______________________________________

From report at bugs.python.org  Fri Jul  8 20:16:59 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Jul 2011 18:16:59 +0000
Subject: [issue12518] In string.Template it's impossible to transform
	delimiter in the derived class
In-Reply-To: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>
Message-ID: <1310149019.37.0.23107819605.issue12518@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

3.1 is in security fixes-only mode

----------
nosy: +SilentGhost
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12518>
_______________________________________

From report at bugs.python.org  Fri Jul  8 21:27:45 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 08 Jul 2011 19:27:45 +0000
Subject: [issue12517] Large file support on Windows: sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: <1310153265.8.0.54103018341.issue12517@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12517>
_______________________________________

From report at bugs.python.org  Fri Jul  8 21:37:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 19:37:32 +0000
Subject: [issue11512] adding test suite for cgitb
In-Reply-To: <CAEDCBpeE9RynbwUCCvYLOu4ctenYxieMGJiGY7UwHF0PA9VcsQ@mail.gmail.com>
Message-ID: <1310153796.30059.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Pretty sure it has nothing to do with the new cgitb test.  Apparently
> testPasswordProtectedSite (test.test_robotparser.NetworkTestCase) uses
> website http://mueblesmoraleda.com to run it's test and that site is
> currently down.

Indeed. It's actually related to that + the fact that this particular
buildbot uses OpenDNS. Fixed in 71fed8437db1 and friends.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11512>
_______________________________________

From report at bugs.python.org  Fri Jul  8 23:38:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jul 2011 21:38:37 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <E1QfIkt-0004HM-PN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 638039a4fef3 by Antoine Pitrou in branch 'default':
Issue #11863: remove unused file Python/thread_wince.h
http://hg.python.org/cpython/rev/638039a4fef3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Fri Jul  8 23:47:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Jul 2011 21:47:00 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1310161620.89.0.497581690051.issue8716@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I haven't seen any failures yet so let's close it.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Fri Jul  8 23:52:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jul 2011 21:52:46 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <E1QfIyb-0005FQ-CV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0aa3f90f0830 by Antoine Pitrou in branch 'default':
Issue #11863: Remove support for legacy systems deprecated in Python 3.2
http://hg.python.org/cpython/rev/0aa3f90f0830

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Fri Jul  8 23:54:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 21:54:48 +0000
Subject: [issue12520] spurious output in test_warnings
In-Reply-To: <1310162087.96.0.0645657657853.issue12520@psf.upfronthosting.co.za>
Message-ID: <1310162087.96.0.0645657657853.issue12520@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ ./python -m test test_warnings
[1/1] test_warnings
test.test_warnings:553: UserWarning: test

Also, I don't understand how test_filename_none is supposed to check for issue #12467 (it doesn't use a subprocess).

----------
assignee: haypo
components: Tests
messages: 140043
nosy: haypo, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: spurious output in test_warnings
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12520>
_______________________________________

From report at bugs.python.org  Fri Jul  8 23:55:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Jul 2011 21:55:35 +0000
Subject: [issue11863] Enforce PEP 11 - remove support for legacy systems
In-Reply-To: <1303085337.86.0.669937619549.issue11863@psf.upfronthosting.co.za>
Message-ID: <1310162135.4.0.209937741971.issue11863@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11863>
_______________________________________

From report at bugs.python.org  Sat Jul  9 01:18:33 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 08 Jul 2011 23:18:33 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310167113.73.0.369715670403.issue12167@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I can confirm what Andreas said - I just removed the two lines referencing the logger in BaseFix, and ran the regression tests - with no failures. So I, too, think those lines should go.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Sat Jul  9 03:34:33 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Sat, 09 Jul 2011 01:34:33 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1310175273.36.0.218803630359.issue12449@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

bdist does not appear to be enabled in 3.3 development branch, is this correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Sat Jul  9 04:03:57 2011
From: report at bugs.python.org (Alastair McCann)
Date: Sat, 09 Jul 2011 02:03:57 +0000
Subject: [issue12521] Mac OS 10.6 Tcl/Tk 8.5 - ActiveState Tcl/Tk 8.5
In-Reply-To: <1310177037.34.0.820762578532.issue12521@psf.upfronthosting.co.za>
Message-ID: <1310177037.34.0.820762578532.issue12521@psf.upfronthosting.co.za>


New submission from Alastair McCann <alastair.mccann at gmail.com>:

I am running Python 3.2 on Mac OSX 10.6.8 I have installed ActiveState Tcl/Tk 8.5.

I installed Python first, and then Tcl/Tk.

When I create a simple script, IDLE crashes every time I try to execute it.

Any suggestions??

----------
components: IDLE
messages: 140046
nosy: almccann
priority: normal
severity: normal
status: open
title: Mac OS 10.6 Tcl/Tk 8.5 - ActiveState Tcl/Tk 8.5
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12521>
_______________________________________

From report at bugs.python.org  Sat Jul  9 04:54:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Jul 2011 02:54:58 +0000
Subject: [issue12518] In string.Template it's impossible to transform
	delimiter in the derived class
In-Reply-To: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>
Message-ID: <1310180098.6.0.586580931743.issue12518@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are correct that this is a feature request as written.  I think there is also a doc bug (the docs should probably mention that changing delimiter after class creation is a no-op).

To add this feature the computation of the regex would need to be moved from the metaclass init to the object init.  The question is, was doing this in a metaclass a design decision (perhaps a micro-optimization?), or a "cute trick" that turns out to cause unintuitive consequences?  I think Barry was involved in adding the Template feature, so I'm adding him as nosy (I don't have a clone handy to check hg annotate).

----------
nosy: +barry, r.david.murray
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12518>
_______________________________________

From report at bugs.python.org  Sat Jul  9 05:21:04 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Sat, 09 Jul 2011 03:21:04 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310181664.29.0.359737758353.issue12344@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

I have made a patch based on your suggestions made to higery, ?ric. I have two questions:

1) In Distributions.get_reinitialized_command should the reinitialization of the subcommands also get passed the kwargs? Unfortunately my understanding of the (sub)command flow is not rock solid.

2) What are your thoughts on an effective test for this? This command does not currently have one. I believe I know a simple way to test the new kwargs functionality but if one were to write a test for get_reinitialized_command I think it should probably test the rest of the function as well.

Thoughts?

----------
hgrepos: +39
nosy: +thomas.holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Sat Jul  9 05:21:34 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Sat, 09 Jul 2011 03:21:34 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310181694.62.0.372418059964.issue12344@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file22615/d863f392c094.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Sat Jul  9 06:27:40 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Jul 2011 04:27:40 +0000
Subject: [issue12521] IDLE 3.2 crashes on Mac OS 10.6 with ActiveState Tcl/Tk
	8.5
In-Reply-To: <1310177037.34.0.820762578532.issue12521@psf.upfronthosting.co.za>
Message-ID: <1310185660.4.0.154339608429.issue12521@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

We need more information to be able to assist you:

1. How do you launch IDLE?  Are you clicking on an icon and, if so, which one, or are you entering a command from a terminal window or something else?

2. When IDLE starts up, what are the exact lines that appear first in the Python Shell window it opens?  It should be something similar to but not identical to:

Python 3.2.1rc1+ (default, Jul  3 2011, 23:55:09) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

3. What is the contents of the script that causes the crash?

4. What are the exact commands you enter to produce the crash?

5. If you aren't already, try launching IDLE from a Terminal.app shell window this way, assuming you used a python.org installer:

   /usr/local/bin/idle3.2

If IDLE crashes, what is reported in the terminal shell window?

Thanks!

----------
assignee:  -> ned.deily
nosy: +ned.deily
stage:  -> test needed
title: Mac OS 10.6 Tcl/Tk 8.5 - ActiveState Tcl/Tk 8.5 -> IDLE 3.2 crashes on Mac OS 10.6 with ActiveState Tcl/Tk 8.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12521>
_______________________________________

From report at bugs.python.org  Sat Jul  9 07:34:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Jul 2011 05:34:16 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1310189656.58.0.933304419863.issue12486@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Hmm. Python 3 code is unicode. "Python reads program text as Unicode code points." The tokenize module purports to provide "a lexical scanner for Python source code". But it seems not to do that. Instead it provides a scanner for Python code encoded as bytes, which is something different. So this is at least a doc update issue (which affects 2.7/3.2 also). Another doc issue is given below.

A deeper problem is that tokenize uses the semi-obsolete readline protocol, which probably dates to 1.0 and which expects the source to be a file or file-like. The more recent iterator protocol would lets the source be anything. A modern tokenize function should accept an iterable of  strings. This would include but not be limited to a file opened in text mode.

A related problem is that 'tokenize' is a convenience function that does several things bundled together.
1. Read lines as bytes from a file-like source.
2. Detect encoding.
3. Decode lines to strings.
4. Actually tokenize the strings to tokens.

I understand this feature request to be a request that function 4, the actual Python 3 code tokenizer be unbundled and exposed to users. I agree with this request. Any user that starts with actual Py3 code would benefit.

(Compile() is another function that bundles a tokenizer.)

Back to the current doc and another doc problem. The entry for untokenize() says "Converts tokens back into Python source code. ...The reconstructed script is returned as a single string." That would be nice if true, but I am going to guess it is not, as the entry continues "It returns bytes, encoded using the ENCODING token,". In Py3, string != bytes, so this seems an incomplete doc conversion from Py2.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12486>
_______________________________________

From report at bugs.python.org  Sat Jul  9 07:42:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Jul 2011 05:42:16 +0000
Subject: [issue12510] IDLE get_the_calltip mishandles raw strings
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1310190136.01.0.461313541472.issue12510@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What platform? It sometimes makes a difference with tcl/tk and hence idle.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12510>
_______________________________________

From report at bugs.python.org  Sat Jul  9 09:34:48 2011
From: report at bugs.python.org (Kenyon Ralph)
Date: Sat, 09 Jul 2011 07:34:48 +0000
Subject: [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1310196888.04.0.45004496815.issue7229@psf.upfronthosting.co.za>


Changes by Kenyon Ralph <kenyon at kenyonralph.com>:


----------
nosy: +kralph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7229>
_______________________________________

From report at bugs.python.org  Sat Jul  9 10:58:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Jul 2011 08:58:09 +0000
Subject: [issue12470] Fix cut&paste typo in test_shutil
In-Reply-To: <1309554153.12.0.611513852686.issue12470@psf.upfronthosting.co.za>
Message-ID: <E1QfTMV-0002Cz-SG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f92bf428c647 by Senthil Kumaran in branch '3.2':
Fix closes issue issue12470 - check for utime for the skipUnless condition.
http://hg.python.org/cpython/rev/f92bf428c647

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12470>
_______________________________________

From report at bugs.python.org  Sat Jul  9 10:58:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Jul 2011 08:58:09 +0000
Subject: [issue12438] IDLE problem displaying warning message
In-Reply-To: <1309309591.85.0.564668230133.issue12438@psf.upfronthosting.co.za>
Message-ID: <E1QfTMV-0002Cz-SN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7dd9313c300b by Senthil Kumaran in branch '3.2':
Fix closes issue12438  - idlelib.PyShell's showformatwarning method was passing an incorrect arg.
http://hg.python.org/cpython/rev/7dd9313c300b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12438>
_______________________________________

From report at bugs.python.org  Sat Jul  9 10:58:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Jul 2011 08:58:10 +0000
Subject: [issue12429] test_io.check_interrupted_write() sporadic failures on
	FreeBSD 6 on Python 2.7/3.2
In-Reply-To: <1309260227.84.0.740113314895.issue12429@psf.upfronthosting.co.za>
Message-ID: <E1QfTMV-0002Cz-S9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ad16e4a0ef80 by Victor Stinner in branch '3.2':
Issue #12429: Skip interrupted write tests on FreeBSD <= 7
http://hg.python.org/cpython/rev/ad16e4a0ef80

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12429>
_______________________________________

From report at bugs.python.org  Sat Jul  9 11:03:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Jul 2011 09:03:46 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1310202226.54.0.882751009246.issue12486@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The compiler has a PyCF_SOURCE_IS_UTF8 flag: see compile() builtin. The parser has a flag to ignore the coding cookie: PyPARSE_IGNORE_COOKIE.

Patch tokenize to support Unicode is simple: use PyCF_SOURCE_IS_UTF8 and/or PyPARSE_IGNORE_COOKIE flags and encode the strings to UTF-8.

Rewrite the parser to work directly on Unicode is much more complex and I don't think that we need that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12486>
_______________________________________

From report at bugs.python.org  Sat Jul  9 11:31:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Jul 2011 09:31:42 +0000
Subject: [issue12510] IDLE get_the_calltip mishandles raw strings
In-Reply-To: <1309994842.51.0.029840708446.issue12510@psf.upfronthosting.co.za>
Message-ID: <1310203902.18.0.984438267831.issue12510@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem is easily reproducible.  Although it shouldn't give that error (and that can be fixed), it seems to me that IDLE should not be trying to give a calltip in that context. What it is trying to do is display the __doc__ attribute of the string but the __doc__ is really for the str() constructor:

>>> 'a'.__doc__
"str(string[, encoding[, errors]]) -> str\n\nCreate a new string object from the given encoded string.\nencoding defaults to the current default string encoding.\nerrors can be 'strict', 'replace' or 'ignore' and defaults to 'strict'."

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12510>
_______________________________________

From report at bugs.python.org  Sat Jul  9 13:59:06 2011
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 09 Jul 2011 11:59:06 +0000
Subject: [issue12522] Implement `os.startfile` under Linux and Mac
In-Reply-To: <1310212746.09.0.561501840609.issue12522@psf.upfronthosting.co.za>
Message-ID: <1310212746.09.0.561501840609.issue12522@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

I want to use `os.startfile` to open a folder in Explorer/Nautilus/Finder. The documentation says that it's only implemented on Windows:

http://docs.python.org/dev/library/os.html#os.startfile

See discussion on Python-ideas here:
https://groups.google.com/forum/?hl=en#!topic/python-ideas/LL0SavbKrEA


Is there a good reason why `os.startfile` is implemented only on Windows?

----------
components: Library (Lib)
messages: 140057
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement `os.startfile` under Linux and Mac
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12522>
_______________________________________

From report at bugs.python.org  Sat Jul  9 14:13:14 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 09 Jul 2011 12:13:14 +0000
Subject: [issue12522] Implement `os.startfile` under Linux and Mac
In-Reply-To: <1310212746.09.0.561501840609.issue12522@psf.upfronthosting.co.za>
Message-ID: <1310213594.21.0.147956395393.issue12522@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I think this is a duplicate of #3177.

----------
nosy: +rosslagerwall
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12522>
_______________________________________

From report at bugs.python.org  Sat Jul  9 14:15:25 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 09 Jul 2011 12:15:25 +0000
Subject: [issue3177] implement os.startfile on posix and MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310213725.07.0.363197320609.issue3177@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Closed #12522 as a duplicate.

It contains a link to a discussion on python-ideas requesting the feature.

----------
nosy: +rosslagerwall
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Sat Jul  9 14:16:05 2011
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 09 Jul 2011 12:16:05 +0000
Subject: [issue3177] implement os.startfile on posix and MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310213765.87.0.891211638047.issue3177@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/issue3177>
_______________________________________

From report at bugs.python.org  Sat Jul  9 15:18:12 2011
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 09 Jul 2011 13:18:12 +0000
Subject: [issue12418] python should inherit the library search path from the
	compiler for stdlib extensions
In-Reply-To: <1309176139.38.0.221668771682.issue12418@psf.upfronthosting.co.za>
Message-ID: <1310217492.08.0.431573047536.issue12418@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

I don't think so. But maybe it would be enough to special case GCC as a unix compiler? At least there are already autoconf checks trying to detect gcc.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12418>
_______________________________________

From report at bugs.python.org  Sat Jul  9 15:27:05 2011
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 09 Jul 2011 13:27:05 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1310218025.74.0.175706858316.issue12326@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

while this is sorted out, I propose to apply the following workaround not to introduce `linux3', at least for the branches:

--- a/configure.in      2011-06-11 17:46:28.000000000 +0200
+++ b/configure.in      2011-06-19 22:32:05.852934453 +0200
@@ -293,6 +293,7 @@
        MACHDEP="$ac_md_system$ac_md_release"
 
        case $MACHDEP in
+       linux3) MACHDEP="linux2";;
        cygwin*) MACHDEP="cygwin";;
        darwin*) MACHDEP="darwin";;
        atheos*) MACHDEP="atheos";;

----------
nosy: +doko
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul  9 15:29:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Jul 2011 13:29:28 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1310218025.74.0.175706858316.issue12326@psf.upfronthosting.co.za>
Message-ID: <1310218112.3677.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> while this is sorted out, I propose to apply the following workaround
> not to introduce `linux3', at least for the branches:

It's too late, since existing versions won't have the patch and will
show "linux3" when the kernel gets upgraded.

I think we'd better bite the bullet and accept the "linux3" value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul  9 15:42:40 2011
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 09 Jul 2011 13:42:40 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1310218960.05.0.0541152440191.issue12326@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

about the plat-*/ files:

they are even wrong for some linux architectures, because some constants like the DLFCN constants have different values depending on the platform/architecture (can't find the issue proposing architecture dependent plat-linux2-<arch> directories).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul  9 15:49:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Jul 2011 13:49:28 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1QfXuQ-0002u8-OI@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 53d2d30d6ca0 by Antoine Pitrou in branch '2.7':
Issue #12326: document the recommended idiom for checking sys.platform on Unix systems.
http://hg.python.org/cpython/rev/53d2d30d6ca0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul  9 15:56:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Jul 2011 13:56:40 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1QfY1O-0003Om-Of@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8bc9dbc61ba6 by Antoine Pitrou in branch '3.2':
Issue #12326: document the recommended idiom for checking sys.platform on Unix systems.
http://hg.python.org/cpython/rev/8bc9dbc61ba6

New changeset 19b3b2d93a63 by Antoine Pitrou in branch 'default':
Issue #12326: document the recommended idiom for checking sys.platform on Unix systems.
http://hg.python.org/cpython/rev/19b3b2d93a63

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:12:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:12:46 +0000
Subject: [issue12519] Call next version 3.3.0
In-Reply-To: <1310133226.52.0.80498205219.issue12519@psf.upfronthosting.co.za>
Message-ID: <1310220766.66.0.914792401845.issue12519@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Benjamin committed 2ebcbdca0dee for patchlevel.h, but idlever, distutils.__init__ and others are not edited yet.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12519>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:25:25 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Jul 2011 14:25:25 +0000
Subject: [issue12519] Call next version 3.3.0
In-Reply-To: <1310220766.66.0.914792401845.issue12519@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o8adkf2u6CraA234VjwxS_wAhy4=ytvnVH27iH9TJ2wOQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/9 ?ric Araujo <report at bugs.python.org>:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Benjamin committed 2ebcbdca0dee for patchlevel.h, but idlever, distutils.__init__ and others are not edited yet.

I don't care that much. When the tree is bumped to 3.0.0a1, those'll be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12519>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:27:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:27:17 +0000
Subject: [issue12519] Call next version 3.3.0
In-Reply-To: <1310133226.52.0.80498205219.issue12519@psf.upfronthosting.co.za>
Message-ID: <1310221637.73.0.36718284924.issue12519@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Then this is done.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12519>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:27:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:27:45 +0000
Subject: [issue8639] Allow callable objects in inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1310221665.93.0.942063652969.issue8639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding to nosy the developers who last touched inspect.

----------
nosy: +benjamin.peterson, eric.araujo, michael.foord, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:27:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:27:54 +0000
Subject: [issue8639] Allow callable objects in inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1310221674.68.0.76443102757.issue8639@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:37:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:37:21 +0000
Subject: [issue5420] Queue deprecation warning patch
In-Reply-To: <1236218557.32.0.700265695834.issue5420@psf.upfronthosting.co.za>
Message-ID: <1310222241.78.0.289433713709.issue5420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the docstrings of empty and full should mention they?re obsolete, to make users of pydoc or other tools aware of the deprecation before they write code using them.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5420>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:40:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:40:26 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1310222426.59.0.690696640736.issue11339@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/issue11339>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:42:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:42:02 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1310222522.76.0.503756235046.issue1553375@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Jul  9 16:44:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Jul 2011 14:44:20 +0000
Subject: [issue11365] Integrate Buildroot patches (cross-compilation)
In-Reply-To: <1299015633.09.0.58407944374.issue11365@psf.upfronthosting.co.za>
Message-ID: <1310222660.86.0.455835144732.issue11365@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No, they?re not the same.

See also my listing of (most of the) cross-compile patches: http://mail.python.org/pipermail/python-dev/2011-March/110099.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11365>
_______________________________________

From report at bugs.python.org  Sat Jul  9 17:31:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Jul 2011 15:31:38 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1310225498.5.0.587949488547.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Once again got close to committing this, but then realised it is missing all the necessary documentation updates for a core language change.

I have uploaded a patch that includes all the changes from Bitbucket as well as the subsequent fixes to avoid modifying sys.stdout when the tests are run and to comply with the whitespace rules set up in the source control hooks (the ACKS, NEWS and a placeholder in whatsnew are also included).

What's missing are updates to at least:

http://docs.python.org/dev/tutorial/classes.html#generators
(a simple example showing delegation should suffice there)

http://docs.python.org/dev/reference/simple_stmts.html#the-yield-statement
http://docs.python.org/dev/reference/expressions.html#grammar-token-yield_expression
http://docs.python.org/dev/reference/simple_stmts.html#the-return-statement
(the language reference must be updated for a post PEP 380 world)

There are likely other places that should also be updated, but these are the critical ones needed before the patch can be included.

----------
keywords: +patch
nosy: +gcewing
Added file: http://bugs.python.org/file22616/pep380-missing-docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:14:10 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 09 Jul 2011 20:14:10 +0000
Subject: [issue8639] Allow callable objects in inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1310242450.5.0.420818387419.issue8639@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/issue8639>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:50:44 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:50:44 +0000
Subject: [issue8639] Allow callable objects in inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1310244644.27.0.171546635619.issue8639@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:51:20 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:51:20 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1310244680.4.0.456216680762.issue11339@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:51:58 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:51:58 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1310244718.67.0.503145448586.issue1294232@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294232>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:52:20 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:52:20 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1310244740.77.0.0560529709491.issue5996@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:53:49 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:53:49 +0000
Subject: [issue12486] tokenize module should have a unicode API
In-Reply-To: <1309751897.67.0.332272921906.issue12486@psf.upfronthosting.co.za>
Message-ID: <1310244829.2.0.631693242939.issue12486@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12486>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:54:27 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:54:27 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1310244867.55.0.181565186396.issue10403@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:54:52 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:54:52 +0000
Subject: [issue12491] Update glossary documentation for the term 'attribute'
In-Reply-To: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>
Message-ID: <1310244892.81.0.535333338237.issue12491@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12491>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:55:28 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:55:28 +0000
Subject: [issue11549] Build-out an AST optimizer,
	moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1310244928.35.0.375776574975.issue11549@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:55:47 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:55:47 +0000
Subject: [issue2377] Replace __import__ w/ importlib.__import__
In-Reply-To: <1205808012.99.0.46136974085.issue2377@psf.upfronthosting.co.za>
Message-ID: <1310244947.85.0.663869452188.issue2377@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2377>
_______________________________________

From report at bugs.python.org  Sat Jul  9 22:57:38 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 20:57:38 +0000
Subject: [issue12374] Execution model should explain compile vs definition vs
	execution time
In-Reply-To: <1308582911.55.0.701954968644.issue12374@psf.upfronthosting.co.za>
Message-ID: <1310245058.49.0.315564383044.issue12374@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12374>
_______________________________________

From report at bugs.python.org  Sat Jul  9 23:31:43 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Jul 2011 21:31:43 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1310247103.83.0.65371505839.issue11435@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Sun Jul 10 02:04:25 2011
From: report at bugs.python.org (Gry)
Date: Sun, 10 Jul 2011 00:04:25 +0000
Subject: [issue12523] 'str' object has no attribute 'more'
	[/usr/lib/python3.2/asynchat.py|initiate_send|245]
In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>
Message-ID: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>


New submission from Gry <gryllida at gmail.com>:

Asynchat push() function has a bug which prevents it from functioning.

This code worked fine with Python 2.

---------------------------------------------------------------
# https://github.com/jstoker/BasicBot
import asynchat,asyncore,socket
class asynchat_bot(asynchat.async_chat):
def __init__(self, host, port):
asynchat.async_chat.__init__(self)
self.create_socket(socket.AF_INET,socket.SOCK_STREAM)
self.set_terminator('\r\n')
self.data=''
self.remote=(host,port)
self.connect(self.remote)

def handle_connect(self):
self.push('USER BasicBot 8 %s :BasicBot! http://github.com/jstoker/BasicBot\r\nNICK testbot\r\n' % self.remote[0])

def get_data(self):
r=self.data
self.data=''
return r
def collect_incoming_data(self, data):
self.data+=data
def found_terminator(self):
data=self.get_data()
if data[:4] == 'PING':
self.push('PONG %s' % data[5:]+'\r\n')
if '001' in data:
self.push('JOIN #bots\r\n')
if '~hi' in data:
self.push('PRIVMSG #bots :hi.\r\n')
if __name__ == '__main__':
asynchat_bot('127.0.0.1',16667)
asyncore.loop()
---------------------------------------------------------------


In Python 3 however, the exception follows:


---------------------------------------------------------------
~/tests/BasicBot$ python3 asynchat_bot.py
error: uncaptured python exception, closing channel <__main__.asynchat_bot connected at 0xb70078ac> (<class 'AttributeError'>:'str' object has no attribute 'more' [/usr/lib/python3.2/asyncore.py|write|89] [/usr/lib/python3.2/asyncore.py|handle_write_event|462] [/usr/lib/python3.2/asynchat.py|handle_write|194] [/usr/lib/python3.2/asynchat.py|initiate_send|245])
~/tests/BasicBot$ python3 -V
Python 3.2
~/tests/BasicBot$
---------------------------------------------------------------

A comment from Stackoverflow on why it happens:

---------------------------------------------------------------
The error seems to be raised in /usr/lib/python3.2/asynchat.py|initiate_send|245.

def initiate_send(self):
    while self.producer_fifo and self.connected:
        first = self.producer_fifo[0]
        ...
        try:
            data = buffer(first, 0, obs)
        except TypeError:
            data = first.more() <--- here 

Seems like somebody put a string in self.producer_fifo instead of an asyncchat.simple_producer, which is the only class in async*.py with a more() method.

----------
components: None
messages: 140073
nosy: Gry
priority: normal
severity: normal
status: open
title: 'str' object has no attribute 'more' [/usr/lib/python3.2/asynchat.py|initiate_send|245]
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12523>
_______________________________________

From report at bugs.python.org  Sun Jul 10 02:53:09 2011
From: report at bugs.python.org (Jimmy Cao)
Date: Sun, 10 Jul 2011 00:53:09 +0000
Subject: [issue12523] 'str' object has no attribute 'more'
	[/usr/lib/python3.2/asynchat.py|initiate_send|245]
In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>
Message-ID: <1310259189.9.0.423932286397.issue12523@psf.upfronthosting.co.za>


Changes by Jimmy Cao <jcao219 at gmail.com>:


----------
nosy: +jcao219

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12523>
_______________________________________

From report at bugs.python.org  Sun Jul 10 10:36:52 2011
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 10 Jul 2011 08:36:52 +0000
Subject: [issue3177] implement os.startfile on posix and MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310287012.98.0.853878161167.issue3177@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Sun Jul 10 11:05:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Jul 2011 09:05:32 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

The POST example in the httplib docs references musi-cal.mojam.com, which is now defunct.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 140074
nosy: docs at python, georg.brandl
priority: low
severity: normal
status: open
title: change httplib docs POST example

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Sun Jul 10 13:18:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Jul 2011 11:18:17 +0000
Subject: [issue12491] Update glossary documentation for the term 'attribute'
In-Reply-To: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>
Message-ID: <1310296697.39.0.0453799711485.issue12491@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The current glossary entry is fine and encompasses was is ordinarily meant by attribute as distinct from a method.

We sometimes use the term loosely to mean any value whether callable or not.  And sometimes it is used loosely to mean anything that can be looked up with getattr().

Attempts to over-define it will be incorrect for some uses.  Also, it is likely to make the glossary entry less understandable.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12491>
_______________________________________

From report at bugs.python.org  Sun Jul 10 14:44:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jul 2011 12:44:20 +0000
Subject: [issue12491] Update glossary documentation for the term 'attribute'
In-Reply-To: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>
Message-ID: <1310301860.85.0.238863450492.issue12491@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As an experienced Python programmer, I think of 'attribute' as meaning any attribute (method or non-method) of an object or class.  I sometimes do use it imprecisely (to my mind) to mean "non-method attribute", and it is usually clear from context what I mean.

Raymond, if attribute means only non-method attributes, what is the word for the set of things that contains both method and non-method...ah, attributes...of an object?

(I thought we already had this discussion both on python-dev and another issue....)

Hmm.  Actually looking at the linked entry, it looks correct to me (it covers both method and non-method attributes as far as I can see).  It might be clearer if it mentioned that a value can be anything, including a method.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12491>
_______________________________________

From report at bugs.python.org  Sun Jul 10 14:47:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jul 2011 12:47:23 +0000
Subject: [issue12523] 'str' object has no attribute 'more'
	[/usr/lib/python3.2/asynchat.py|initiate_send|245]
In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>
Message-ID: <1310302043.06.0.866970851612.issue12523@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Library (Lib) -None
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12523>
_______________________________________

From report at bugs.python.org  Sun Jul 10 14:49:42 2011
From: report at bugs.python.org (Amandeep Singh)
Date: Sun, 10 Jul 2011 12:49:42 +0000
Subject: [issue12525] Unable to run a thread
In-Reply-To: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>
Message-ID: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>


New submission from Amandeep Singh <newtodisworld at gmail.com>:

I created a thread, and started it and then called its run method. It raised an AttributeError exception


from threading import Thread

def func():
  print 'abc'

t = Thread(None, func)
t.start()
t.run()

here t.run() raises an exception.

----------
components: Build
messages: 140077
nosy: newtodisworld
priority: normal
severity: normal
status: open
title: Unable to run a thread
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12525>
_______________________________________

From report at bugs.python.org  Sun Jul 10 14:51:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jul 2011 12:51:15 +0000
Subject: [issue12523] 'str' object has no attribute 'more'
	[/usr/lib/python3.2/asynchat.py|initiate_send|245]
In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>
Message-ID: <1310302275.59.0.339886928996.issue12523@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12523>
_______________________________________

From report at bugs.python.org  Sun Jul 10 14:54:05 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jul 2011 12:54:05 +0000
Subject: [issue12491] Update glossary documentation for the term 'attribute'
In-Reply-To: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>
Message-ID: <1310302445.28.0.814815647002.issue12491@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, I found the other issue and it looks like we agreed to use 'attributes and methods' where the reference was inclusive.  I still think that it is less precise to think this way, but it is clearer exposition given the lack of a good term for non-method attributes.  So now I agree that we should not change the existing glossary definition of attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12491>
_______________________________________

From report at bugs.python.org  Sun Jul 10 14:58:14 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 10 Jul 2011 12:58:14 +0000
Subject: [issue12525] Unable to run a thread
In-Reply-To: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>
Message-ID: <1310302694.19.0.804613792815.issue12525@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Don't call both start() and run(). From the documentation, start() arranges for run() to be called. After the call to start(), 'abc' is printed.

----------
components: +Extension Modules -Build
nosy: +eric.smith
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12525>
_______________________________________

From report at bugs.python.org  Sun Jul 10 15:13:22 2011
From: report at bugs.python.org (Amandeep Singh)
Date: Sun, 10 Jul 2011 13:13:22 +0000
Subject: [issue12525] Unable to run a thread
In-Reply-To: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>
Message-ID: <1310303602.4.0.466726588382.issue12525@psf.upfronthosting.co.za>


Amandeep Singh <newtodisworld at gmail.com> added the comment:

I am also not able to call run() twice. I have python 2.5.2 with me, in which I am able to call run method twice and calling run after start is working.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12525>
_______________________________________

From report at bugs.python.org  Sun Jul 10 15:18:38 2011
From: report at bugs.python.org (Amandeep Singh)
Date: Sun, 10 Jul 2011 13:18:38 +0000
Subject: [issue12525] Unable to run a thread
In-Reply-To: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>
Message-ID: <1310303918.81.0.0353622470104.issue12525@psf.upfronthosting.co.za>


Amandeep Singh <newtodisworld at gmail.com> added the comment:

May be this is a behavior change, that a thread can not be run again. I think documentation needs to be changed in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12525>
_______________________________________

From report at bugs.python.org  Sun Jul 10 15:22:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Jul 2011 13:22:38 +0000
Subject: [issue12525] Unable to run a thread
In-Reply-To: <1310302182.7.0.901350004785.issue12525@psf.upfronthosting.co.za>
Message-ID: <1310304158.25.0.46792496224.issue12525@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

While it's not explicitly documented that run() also shouldn't be called multiple times, it does not need to be supported.  Threads can be started exactly once -- this is already mentioned in the docs.

Note that run() simply calls the thread target with the given args.  Calling thread.run() instead is just a more confusing way of doing this.

----------
nosy: +georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12525>
_______________________________________

From report at bugs.python.org  Sun Jul 10 17:40:48 2011
From: report at bugs.python.org (Michael Mulich)
Date: Sun, 10 Jul 2011 15:40:48 +0000
Subject: [issue12526] packaging.pypi.Crawler and resulting objects have a
	circular API
In-Reply-To: <1310312448.84.0.700662725694.issue12526@psf.upfronthosting.co.za>
Message-ID: <1310312448.84.0.700662725694.issue12526@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

The issue, as best I can describe it, is in how the a release list (packaging.pypi.dist.ReleaseList) looks up releases.

Here is a simple example using a random package on PyPI.

>>> crawler = Crawler()
>>> projects = crawler.search_projects('snimpy')
>>> projects
[<Project "snimpy">]
>>> project = projects[0]
>>> [x for x in project]
[]

The results show that project 'snimpy' has no releases, but this is incorrect because distribution 'snimpy' has five releases.

Even after calling sort_releases and fetch_releases on the project which both refer back to the crawler instance (see the project's _index attribute) the project fails to get the releases.

>>> project.fetch_releases()
[]
>>> project.sort_releases()
>>> [x for x in project]
[]

In order to get the releases, one is forced to use the crawler's
API rather than the resulting project's API.

>>> crawler.get_releases(project.name, force_update=True)
<Project "snimpy" versions: 0.5, 0.4, 0.3, 0.2.1, 0.2>
>>> [x for x in project]
[<snimpy 0.5>, <snimpy 0.4>, <snimpy 0.3>, <snimpy 0.2.1>, <snimpy 0.2>]

So as far as I can gather, We lack the ability to forcibly update the project (or ReleaseList). I don't have a solution at this time, but we may want to look into adding a force_update argument to the get_release method on the Crawler.

----------
assignee: tarek
components: Distutils2
messages: 140083
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: packaging.pypi.Crawler and resulting objects have a circular API
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12526>
_______________________________________

From report at bugs.python.org  Sun Jul 10 18:34:50 2011
From: report at bugs.python.org (Brian Jones)
Date: Sun, 10 Jul 2011 16:34:50 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

The documentation here:
http://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertRaisesRegex

Indicates that, when used as a context manager, assertRaisesRegex should accept a keyword argument 'msg'. However, that doesn't appear to actually be implemented. I've just now done an hg pull, and in Lib/unittest/case.py, the source is here: 

    def assertRaisesRegex(self, expected_exception, expected_regex,
                          callable_obj=None, *args, **kwargs):
        """Asserts that the message in a raised exception matches a regex.

        Args:
            expected_exception: Exception class expected to be raised.
            expected_regex: Regex (re pattern object or string) expected
                    to be found in error message.
            callable_obj: Function to be called.
            msg: Optional message used in case of failure. Can only be used
                    when assertRaisesRegex is used as a context manager.
            args: Extra args.
            kwargs: Extra kwargs.
        """
        context = _AssertRaisesContext(expected_exception, self, callable_obj,
                                       expected_regex)

        return context.handle('assertRaisesRegex', callable_obj, args, kwargs)

I noticed this after attempting some simple example uses of assertRaisesRegex. Perhaps I'm just missing something that will be made obvious to others by seeing them. These are just various attempts to get my msg shown somewhere in the output: 

#!/usr/bin/env python3.3
import unittest

class TestInt(unittest.TestCase):
    def test_intfail(self):
        # this test should *not* fail, and doesn't
        with self.assertRaisesRegex(ValueError, 'literal'):
            int('XYZ')

    def test_intfail2(self):
        # should not fail, and doesn't
        with self.assertRaisesRegex(ValueError, 'lambda', msg='Foo!'):
            int('ABC')

    def test_intfail3(self):
        # should fail, and does, but no msg to be found.
        with self.assertRaisesRegex(ValueError, 'literal', msg='Foo!'):
            int(1)

    def test_intfail4(self):
        # should fail, and does, but no msg to be found.
        with self.assertRaisesRegex(TypeError, 'literal', msg='Foo!'):
            int('ABC')

if __name__ == '__main__':
    unittest.main()

----------
components: Library (Lib)
messages: 140084
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: assertRaisesRegex doc'd with 'msg' arg, but it's not implemented?
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Sun Jul 10 19:29:02 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Jul 2011 17:29:02 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1310318942.81.0.434394525989.issue12527@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You're not getting this?

.FFE
======================================================================
ERROR: test_intfail4 (__main__.TestInt)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "x.py", line 22, in test_intfail4
    int('ABC')
ValueError: invalid literal for int() with base 10: 'ABC'

======================================================================
FAIL: test_intfail2 (__main__.TestInt)
----------------------------------------------------------------------
ValueError: invalid literal for int() with base 10: 'ABC'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "x.py", line 12, in test_intfail2
    int('ABC')
AssertionError: "lambda" does not match "invalid literal for int() with base 10: 'ABC'" : Foo!

======================================================================
FAIL: test_intfail3 (__main__.TestInt)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "x.py", line 17, in test_intfail3
    int(1)
AssertionError: ValueError not raised : Foo!

----------------------------------------------------------------------
Ran 4 tests in 0.001s

FAILED (failures=2, errors=1)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Sun Jul 10 19:45:06 2011
From: report at bugs.python.org (Brian Jones)
Date: Sun, 10 Jul 2011 17:45:06 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1310319906.95.0.977084793893.issue12527@psf.upfronthosting.co.za>


Brian Jones <bkjones at gmail.com> added the comment:

No, I'm not. I'm sorry for not including this output initially. Here's what I get (and I've added a sys.version_info line just to be double sure the right executable is being invoked at runtime): 

sys.version_info(major=3, minor=3, micro=0, releaselevel='alpha', serial=0)
.FFE
======================================================================
ERROR: test_intfail4 (__main__.TestInt)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test_int.py", line 21, in test_intfail4
    int('ABC')
ValueError: invalid literal for int() with base 10: 'ABC'

======================================================================
FAIL: test_intfail2 (__main__.TestInt)
----------------------------------------------------------------------
ValueError: invalid literal for int() with base 10: 'ABC'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./test_int.py", line 13, in test_intfail2
    int('ABC')
AssertionError: "lambda" does not match "invalid literal for int() with base 10: 'ABC'"

======================================================================
FAIL: test_intfail3 (__main__.TestInt)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test_int.py", line 17, in test_intfail3
    int(1)
AssertionError: ValueError not raised

----------------------------------------------------------------------
Ran 4 tests in 0.001s

FAILED (failures=2, errors=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Sun Jul 10 19:46:58 2011
From: report at bugs.python.org (Brian Jones)
Date: Sun, 10 Jul 2011 17:46:58 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1310320018.86.0.597400661167.issue12527@psf.upfronthosting.co.za>


Brian Jones <bkjones at gmail.com> added the comment:

If there's some reason, based on the source snippet I posted from case.py, that my msg should be making it to the output, can someone explain why/how it should get there? I don't see any reason, from looking at the source, that 'msg' should even be expected to make it to the output.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Sun Jul 10 21:52:37 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 10 Jul 2011 19:52:37 +0000
Subject: [issue12528] Implement configurable bitfield allocation strategy
In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>
Message-ID: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>


New submission from Vlad Riscutia <riscutiavlad at gmail.com>:

Opened this issue to track configurable bitfield allocation strategy. This will address issues like http://bugs.python.org/issue6069, http://bugs.python.org/issue11920.

Summary: the way bitfields are allocated is up to the compiler not defined by standard. MSVC and GCC have different strategies to perform the allocation so the size of bitfield structures can be different depending on compiler. Currently we hardcode allocation strategy to be GCC-way on non-Windows and MSVC-way on Windows which raises issues when trying to interop on Windows with GCC binaries.

Short term this solution will enable interop between MSVC compiled Python with GCC compiled binaries under Windows. It will also enable addressing other possible compiler interop issues in the future, for compilers that don't use GCC strategy.

Following is copied from thread discussing this:


On 6/25/2011 12:33 PM, Vlad Riscutia wrote:
I recently started looking at some ctypes issues. I dug a bit into
http://bugs.python.org/issue6069 and then I found
http://bugs.python.org/issue11920. They both boil down to the fact that
bitfield allocation is up to the compiler, which is different in GCC and
MSVC. Currently we have hard-coded allocation strategy based on paltform
in cfields.c:

 if (bitsize /* this is a bitfield request */

       &&  *pfield_size /* we have a bitfield open */
 #ifdef MS_WIN32
       /* MSVC, GCC with -mms-bitfields */
       &&  dict->size * 8 == *pfield_size
 #else
       /* GCC */
       &&  dict->size * 8<= *pfield_size
 #endif
       &&  (*pbitofs + bitsize)<= *pfield_size) {
       /* continue bit field */
       fieldtype = CONT_BITFIELD;
 #ifndef MS_WIN32
   } else if (bitsize /* this is a bitfield request */
       &&  *pfield_size /* we have a bitfield open */
       &&  dict->size * 8>= *pfield_size
       &&  (*pbitofs + bitsize)<= dict->size * 8) {
       /* expand bit field */
       fieldtype = EXPAND_BITFIELD;
 #endif

So when creating a bitfield structure, it's size can be different on
Linux vs Windows.

class MyStructure(ctypes.BigEndianStructure):
    _pack_      = 1    # aligned to 8 bits, not ctypes default of 32
    _fields_    = [
                   ("Data0",   ctypes.c_uint32, 32),
                   ("Data1",   ctypes.c_uint8, 3),
                   ("Data2",   ctypes.c_uint16, 12),
                  ]

sizeof for above structure is 6 on GCC build and 7 on MSVC build. This
leads to some confusion and issues, because we can't always interop
correctly with code compiled with different compiler than the one Python
is compiled with on the platform.

Just curious, are you saying that this is the 'cause' of the two bug reports, or 'just' something you discovered while investigating them?


> Short term solution is to add a warning in the documentation about this.

For 2.7/3.2, yes.


> Longer term though, I think it
would be better to add a property on the Structure class for
configurable allocation strategy, for example Native (default), GCC,
MSVC and when allocating the bitfield, use given strategy. Native would
behave similar to what happens now, but we would also allow GCC-style
allocation on Windows for example and the ability to extend this if we
ever run into similar issues with other compilers. This shouldn't be too
difficult to implement, will be backwards compatible and it would
improve interop. I would like to hear some opinions on this.

If this would allow the MSVC-compilied Python to better access dlls compiled with gcc (cygwin) on Windows, definitely -- in 3.3.
If the new feature is (currently) only useful on Windows, doc should say so.

-- 
Terry Jan Reedy

/copy

Attached is patch with initial refactoring of cfield.c to enable configurable allocation. Next step is to provide a way to configure this through Python library. I will also look at updating documentation to point out the known issue.

----------
components: ctypes
files: cfield_bitfield_refactoring.diff
keywords: patch
messages: 140088
nosy: terry.reedy, vladris
priority: normal
severity: normal
status: open
title: Implement configurable bitfield allocation strategy
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22617/cfield_bitfield_refactoring.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12528>
_______________________________________

From report at bugs.python.org  Sun Jul 10 22:02:28 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 10 Jul 2011 20:02:28 +0000
Subject: [issue11920] ctypes: Strange bitfield structure sizing issue
In-Reply-To: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za>
Message-ID: <1310328148.36.0.248639031851.issue11920@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Opened http://bugs.python.org/issue12528 to address this.

----------
nosy: +vladris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11920>
_______________________________________

From report at bugs.python.org  Sun Jul 10 22:03:28 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 10 Jul 2011 20:03:28 +0000
Subject: [issue6069] casting error from ctypes array to structure
In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za>
Message-ID: <1310328208.22.0.866933818239.issue6069@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Opened http://bugs.python.org/issue12528 to address this.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6069>
_______________________________________

From report at bugs.python.org  Sun Jul 10 22:16:29 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sun, 10 Jul 2011 20:16:29 +0000
Subject: [issue12528] Implement configurable bitfield allocation strategy
In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>
Message-ID: <1310328989.12.0.421064636139.issue12528@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12528>
_______________________________________

From report at bugs.python.org  Sun Jul 10 22:56:05 2011
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 10 Jul 2011 20:56:05 +0000
Subject: [issue12529] cgi.parse_header fails on double quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>


New submission from Ben Darnell <ben.darnell at gmail.com>:

cgi.parse_header doesn't work on headers that contain combinations of double quotes and semicolons (although it works with either type of character individually).  

>>> cgi.parse_header('form-data; name="files"; filename="fo\\"o;bar"')
('form-data', {'name': 'files', 'filename': '"fo\\"o'})

This issue is present in python 2.7 and 3.2.  One solution is to change _parseparam as follows (same as email.message._parseparam):

def _parseparam(s):
    while s[:1] == ';':
        s = s[1:]
        end = s.find(';')
        while end > 0 and (s.count('"', 0, end) - s.count('\\"', 0, end)) % 2:
            end = s.find(';', end + 1)
        if end < 0:
            end = len(s)
        f = s[:end]
        yield f.strip()
        s = s[end:]

----------
messages: 140091
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: cgi.parse_header fails on double quotes and semicolons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12529>
_______________________________________

From report at bugs.python.org  Mon Jul 11 00:39:00 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 10 Jul 2011 22:39:00 +0000
Subject: [issue12528] Implement configurable bitfield allocation strategy
In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>
Message-ID: <1310337540.58.0.852653164775.issue12528@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Removed previously attached partial patch, this is complete patch.

Summary:
Added following 3 constants in ctypes:
ctypes.BITFIELD_ALLOCATION_NATIVE
ctypes.BITFIELD_ALLOCATION_GCC
ctypes.BITFIELD_ALLOCATION_MSVC

Setting _bitfield_allocation_ attribute to one of these on a class declaration inheriting from Structure will force specified allocation of the bitfield.

NATIVE is equivalent to not specifying anything. 
GCC will do GCC-style allocation (what Python does now on non-Windows)
MSVC will do MSVC-style allocation (what Python does now on Windows)

I added unittests to cover these and ran full suit on both Windows and Linux.

Still have to update documentation to mention this. Will submit diff for that after this gets reviewed.

----------
Added file: http://bugs.python.org/file22618/configurable_bitfield_allocation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12528>
_______________________________________

From report at bugs.python.org  Mon Jul 11 00:39:18 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 10 Jul 2011 22:39:18 +0000
Subject: [issue12528] Implement configurable bitfield allocation strategy
In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>
Message-ID: <1310337558.3.0.96105733417.issue12528@psf.upfronthosting.co.za>


Changes by Vlad Riscutia <riscutiavlad at gmail.com>:


Removed file: http://bugs.python.org/file22617/cfield_bitfield_refactoring.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12528>
_______________________________________

From report at bugs.python.org  Mon Jul 11 00:58:59 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Jul 2011 22:58:59 +0000
Subject: [issue12491] Update glossary documentation for the term 'attribute'
In-Reply-To: <1309814675.46.0.717017747157.issue12491@psf.upfronthosting.co.za>
Message-ID: <1310338739.65.0.332388030118.issue12491@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12491>
_______________________________________

From report at bugs.python.org  Mon Jul 11 01:40:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Jul 2011 23:40:40 +0000
Subject: [issue12343] ssl documentation needs comments about non-blocking
	behaviour
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <E1Qg3c7-0000xV-A6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b763c1ba5589 by Antoine Pitrou in branch '3.2':
Issue #12343: Add some notes on behaviour of non-blocking SSL sockets.
http://hg.python.org/cpython/rev/b763c1ba5589

New changeset 77334eb5038d by Antoine Pitrou in branch 'default':
Issue #12343: Add some notes on behaviour of non-blocking SSL sockets.
http://hg.python.org/cpython/rev/77334eb5038d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Mon Jul 11 01:42:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Jul 2011 23:42:05 +0000
Subject: [issue12343] ssl documentation needs comments about non-blocking
	behaviour
In-Reply-To: <1308187568.46.0.159826705626.issue12343@psf.upfronthosting.co.za>
Message-ID: <1310341325.84.0.241134517679.issue12343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'd say this is fixed now. Tell me if there are any precisions you would like to see added.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12343>
_______________________________________

From report at bugs.python.org  Mon Jul 11 02:21:39 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Mon, 11 Jul 2011 00:21:39 +0000
Subject: [issue8161] inconsistency behavior in ctypes.c_char_p dereferencing
In-Reply-To: <1268816987.2.0.0650705594073.issue8161@psf.upfronthosting.co.za>
Message-ID: <1310343699.44.0.116451882452.issue8161@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Looks like this was implemented by design at some point. In cfield.c, we have specific code to treat character array fields as strings:

    /*  Field descriptors for 'c_char * n' are be scpecial cased to
        return a Python string instead of an Array object instance...
    */
    if (PyCArrayTypeObject_Check(proto)) {
        StgDictObject *adict = PyType_stgdict(proto);
        StgDictObject *idict;
        if (adict && adict->proto) {
            idict = PyType_stgdict(adict->proto);
            if (!idict) {
                PyErr_SetString(PyExc_TypeError,
                                "has no _stginfo_");
                Py_DECREF(self);
                return NULL;
            }
            if (idict->getfunc == _ctypes_get_fielddesc("c")->getfunc) {
                struct fielddesc *fd = _ctypes_get_fielddesc("s");
                getfunc = fd->getfunc;
                setfunc = fd->setfunc;
            }
#ifdef CTYPES_UNICODE
            if (idict->getfunc == _ctypes_get_fielddesc("u")->getfunc) {
                struct fielddesc *fd = _ctypes_get_fielddesc("U");
                getfunc = fd->getfunc;
                setfunc = fd->setfunc;
            }
#endif
        }
    }

Simple fix would be to just remove this whole section though this might break code which relied on string assignment to such fields. For example:

class T(ctypes.Structure):
	_fields_ = (
		('member', ctypes.c_char * 16),
	)

x = T()
x.member = bytes('Spam', 'ascii')

Above works now but will fail if change is made. There is a high chance this would break existing code as I imagine people using this due to convenience. An alternative would be to keep string setfunc but don't change getfunc, though that is also pretty inconsistent as you will be able to set a string but not get one back.

If we are willing to take the risk, fix is easy.

----------
nosy: +vladris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8161>
_______________________________________

From report at bugs.python.org  Mon Jul 11 03:15:27 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Mon, 11 Jul 2011 01:15:27 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1310346927.49.0.0704049744474.issue6493@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

I have a similar patch for issue 6068. I wasn't aware of this issue when I looked into it.

I believe both patches fix the same thing (please take a look and correct me if I'm wrong). My fix: we don't need to treat Windows differently, just remove #ifdef and 

#define BIT_MASK(size) ((1LL << NUM_BITS(size))-1)

regardless of platform. Unittests for this patch pass for my patch too. I believe this is some old #ifdef that was put in place due to a compiler bug which got fixed since then.

----------
nosy: +vladris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6493>
_______________________________________

From report at bugs.python.org  Mon Jul 11 04:02:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 02:02:20 +0000
Subject: [issue12529] cgi.parse_header fails on double quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <1310349740.6.0.911096095479.issue12529@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The email module header parser handles this correctly (if you make it a real header).  For whatever that's worth :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12529>
_______________________________________

From report at bugs.python.org  Mon Jul 11 06:16:14 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Mon, 11 Jul 2011 04:16:14 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1310357774.5.0.0050907585447.issue12142@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

I ran full test suit after making the _array_type = type(Array) change and everything passes.

I also took a look at this and found additional leak. gc shows this as garbage:

[(<class '_ctypes._SimpleCData'>,), <class 'ctypes.c_longdouble'>, <attribute '_
_dict__' of 'c_longdouble' objects>, <attribute '__weakref__' of 'c_longdouble'
objects>, (<class 'ctypes.c_longdouble'>, <class '_ctypes._SimpleCData'>, <class
 '_ctypes._CData'>, <class 'object'>), {'__dict__': <attribute '__dict__' of 'c_
longdouble' objects>, '_type_': 'g', '__module__': 'ctypes', '__weakref__': <att
ribute '__weakref__' of 'c_longdouble' objects>, '__doc__': None}]

This is all caused by these lines in ctypes __init__.py:

class c_longdouble(_SimpleCData):
    _type_ = "g"
if sizeof(c_longdouble) == sizeof(c_double):
    c_longdouble = c_double

For me sizeof(c_longdouble) == sizeof(c_double) (I believe MS compiler always does this) but when we assign c_longdouble = c_double, there is a leak. I removed the alias lines:

if sizeof(c_longdouble) == sizeof(c_double):
    c_longdouble = c_double

And the leak was gone. Looks like changing c_longdouble after declaring it causes a leak. Below for similar aliasing of longlong types, we have this:

if _calcsize("l") == _calcsize("q"):
    # if long and long long have the same size, make c_longlong an alias for c_long
    c_longlong = c_long
    c_ulonglong = c_ulong
else:
    class c_longlong(_SimpleCData):
        _type_ = "q"
    _check_size(c_longlong)

    class c_ulonglong(_SimpleCData):
        _type_ = "Q"

This avoids declaring c_longlong and c_ulonglong as class if not needed to. The problem is _calcsize("g") causes an error because "g" is used as long double througout ctypes but _calcsize is function from _struct.c, where "g" (long double) is not defined. Not sure why it isn't...

So in short:
As far as I can tell _array_type = type(Array) doesn't break anything
Looks like we have another leak in ctypes (which isn't a big deal)
We have elegant fix for the leak once _struct.c will support long double

----------
nosy: +vladris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12142>
_______________________________________

From report at bugs.python.org  Mon Jul 11 06:47:56 2011
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 11 Jul 2011 04:47:56 +0000
Subject: [issue12530] cpython 3.3, __class__ missing.
In-Reply-To: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>
Message-ID: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

In python 3.2 this works and prints <class '__main__.Test'>,
in cpython hg: 71296:ab162f925761 it fails with:
 NameError: global name '__class__' is not defined

Since this change is not documented I assume its a bug.

--- snip ---
class Test:
  def __init__(self): print(__class__)

----------
components: Interpreter Core
messages: 140099
nosy: ideasman42
priority: normal
severity: normal
status: open
title: cpython 3.3, __class__ missing.
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12530>
_______________________________________

From report at bugs.python.org  Mon Jul 11 06:48:46 2011
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 11 Jul 2011 04:48:46 +0000
Subject: [issue12530] cpython 3.3, __class__ missing.
In-Reply-To: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>
Message-ID: <1310359726.04.0.717022266562.issue12530@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

checked for docs here:
http://docs.python.org/dev/whatsnew/3.3.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12530>
_______________________________________

From report at bugs.python.org  Mon Jul 11 06:54:22 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 11 Jul 2011 04:54:22 +0000
Subject: [issue12530] cpython 3.3, __class__ missing.
In-Reply-To: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>
Message-ID: <1310360062.82.0.830830733353.issue12530@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

No, this is consistent (again) with Python 2.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12530>
_______________________________________

From report at bugs.python.org  Mon Jul 11 07:19:49 2011
From: report at bugs.python.org (Alec Koumjian)
Date: Mon, 11 Jul 2011 05:19:49 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1310361589.38.0.000599511922664.issue2636@psf.upfronthosting.co.za>


Alec Koumjian <akoumjian at gmail.com> added the comment:

I apologize if this is the wrong place for this message. I did not see the link to a separate list.

First let me explain what I am trying to accomplish. I would like to be able to take an unknown regular expression that contains both named and unnamed groups and tag their location in the original string where a match was found. Take the following redundantly simple example:

>>> a_string = r"This is a demo sentence."
>>> pattern = r"(?<a_thing>\w+) (\w+) (?<another_thing>\w+)"
>>> m = regex.search(pattern, a_string)

What I want is a way to insert named/numbered tags into the original string, so that it looks something like this:

r"<a_thing>This</a_thing> <2>is</2> <another_thing>a</another_thing> demo sentence."

The syntax doesn't have to be exactly like that, but you get the place. I have inserted the names and/or indices of the groups into the original string, around the span that the groups occupy. 

This task is exceedingly difficult with the current implementation, unless I am missing something obvious. We could call the groups by index, the groups as a tuple, or the groupdict:

>>> m.group(1)
'This'
>>> m.groups()
('This', 'is', 'a')
>>> m.groupdict()
{'another_thing': 'a', 'a_thing': 'This'}

If all I wanted was to tag the groups by index, it would be a simple function. I would be able to call m.spans() for each index in the length of m.groups() and insert the <> and </> tags around the right indices.

The hard part is finding out how to find the spans of the named groups. Do any of you have a suggestion?

It would make more sense from my perspective, if each group was an object that had its own .span property. It would work like this with the above example:

>>> first = m.group(1)
>>> first.name()
'a_thing'
>>> second = m.group(2)
>>> second.name()
None
>>>

You could still call .spans() on the Match object itself, but it would query its children group objects for the data. Overall I think this would be a much more Pythonic approach, especially given that you have added subscripting and key lookup.

So instead of this:
>>> m['a_thing']
'This'
>>> type(m['a_thing'])
<type 'str'>

You could have:
>>> m['a_thing']
'This'
>>> type(m['a_thing'])
<'regex.Match.Group object'>

With the noted benefit of this:
>>> m['a_thing'].span()
(0, 4)
>>> m['a_thing'].index()
1
>>>

Maybe I'm missing a major point or functionality here, but I've been pouring over the docs and don't currently think what I'm trying to achieve is possible.

Thank you for taking the time to read all this.

-Alec

----------
nosy: +akoumjian
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 11 08:04:07 2011
From: report at bugs.python.org (Nir Aides)
Date: Mon, 11 Jul 2011 06:04:07 +0000
Subject: [issue874900] malloc
Message-ID: <1310364247.35.0.333893954948.issue874900@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
title: threading module can deadlock after fork -> malloc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Mon Jul 11 08:04:45 2011
From: report at bugs.python.org (Nir Aides)
Date: Mon, 11 Jul 2011 06:04:45 +0000
Subject: [issue874900] threading module can deadlock after fork
Message-ID: <1310364285.81.0.203145437314.issue874900@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
title: malloc -> threading module can deadlock after fork

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue874900>
_______________________________________

From report at bugs.python.org  Mon Jul 11 08:34:58 2011
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 11 Jul 2011 06:34:58 +0000
Subject: [issue12530] cpython 3.3, __class__ missing.
In-Reply-To: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>
Message-ID: <1310366098.34.0.523550493277.issue12530@psf.upfronthosting.co.za>


Campbell Barton <ideasman42 at gmail.com> added the comment:

Shouldn't it be documented that it changes still? - since people are using pytjon3.2 and its a stable release, _any_ breaking change should be documented IMHO

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12530>
_______________________________________

From report at bugs.python.org  Mon Jul 11 11:44:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Jul 2011 09:44:17 +0000
Subject: [issue12523] 'str' object has no attribute 'more'
	[/usr/lib/python3.2/asynchat.py|initiate_send|245]
In-Reply-To: <1310256264.97.0.142665013721.issue12523@psf.upfronthosting.co.za>
Message-ID: <1310377457.62.0.207475998726.issue12523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, the error is that in Python 3 you should use bytes objects when transmitting/receiving data over the network, not (unicode) strings.
That is, replace '\r\n' with b'\r\n', etc.

Of course, the error message should be made less obscure.

----------
nosy: +pitrou
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12523>
_______________________________________

From report at bugs.python.org  Mon Jul 11 12:36:31 2011
From: report at bugs.python.org (Elazar Leibovich)
Date: Mon, 11 Jul 2011 10:36:31 +0000
Subject: [issue9329] freeze tool cannot handle JSON module properly
In-Reply-To: <1279815656.66.0.596140100357.issue9329@psf.upfronthosting.co.za>
Message-ID: <1310380591.32.0.309666415489.issue9329@psf.upfronthosting.co.za>


Elazar Leibovich <elazarl at gmail.com> added the comment:

Similar problem occurs if you do not specify

   from encodings import ascii

You can get

   LookupError: unknown encoding: ascii

----------
nosy: +Elazar.Leibovich
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9329>
_______________________________________

From report at bugs.python.org  Mon Jul 11 13:22:43 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 Jul 2011 11:22:43 +0000
Subject: [issue8639] Allow callable objects in inspect.getargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1310383363.83.0.700003513983.issue8639@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Doesn't seem like an unreasonable request. Nick / Benjamin, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Mon Jul 11 13:28:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 11:28:01 +0000
Subject: [issue12530] cpython 3.3, __class__ missing.
In-Reply-To: <1310359676.9.0.347835677335.issue12530@psf.upfronthosting.co.za>
Message-ID: <1310383681.87.0.99158438804.issue12530@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless you can point to a place where the behavior that was fixed is actually documented, this is classed as an implementation detail that was changed (or, more likely, a bug that was fixed).  If this were less obscure or had been in existence for longer, there might be an argument for documenting it, but I'm surprised that anyone noticed this variable, since its existence is not in keeping with how Python works in general.  In fact, it goes completely against my Python intuition that it worked at all.  (I suppose that someone newer to Python would be more likely to find it by accident...)

That said, it is certainly not obvious from Misc/NEWS that this variable went away, so it was presumably fixed as part of some other change.  Given that we *do* have a bug report about it, we should consider if it should be documented somewhere; perhaps an addendum to the relevant Misc/NEWS entry, and then the What's New author can decide whether or not to include it.

(As an aside, note that What's New is not kept up to date, it generally only gets filled in closer to the release date.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12530>
_______________________________________

From report at bugs.python.org  Mon Jul 11 13:29:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Jul 2011 11:29:00 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1310383740.37.0.884014312107.issue5996@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

IIRC, classes weren't supposed to be able inherit from two classes that had different metaclasses (since differing metaclasses don't necessarily play well with one another).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Mon Jul 11 13:48:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 11:48:08 +0000
Subject: [issue1982] Feature: extend strftime to accept milliseconds
In-Reply-To: <1201805956.67.0.436839158391.issue1982@psf.upfronthosting.co.za>
Message-ID: <1310384888.54.0.336523084859.issue1982@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are better off opening a new issue as a feature request.  Do add at least belopolsky as nosy on the new issue.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1982>
_______________________________________

From report at bugs.python.org  Mon Jul 11 13:51:19 2011
From: report at bugs.python.org (Renaud Blanch)
Date: Mon, 11 Jul 2011 11:51:19 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1310385079.21.0.971298221962.issue11682@psf.upfronthosting.co.za>


Renaud Blanch <rndblnch at gmail.com> added the comment:

I can not comment on http://bugs.python.org/review/11682/, so a quick comment here: Doc/whatsnew/3.3.rst patch gives me credit together with Greg Ewing for the implementation, but I've only upgraded his patches to 3.3.
So, the following line:
+(Implementation by Greg Ewing and Renauld Blanch)
should really be:
+(Implementation by Greg Ewing)

And, as I'm on it, the proper spelling for my surname is Renaud (not Renauld as it also appears in the commit message :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:00:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Jul 2011 12:00:15 +0000
Subject: [issue8639] Allow callable objects in inspect.getfullargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1310385615.22.0.628045913601.issue8639@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This API has changed around a bit in 3.x, so it is actually inspect.getfullargspec that needs to change (getargspec will inherit the new behaviour though, since it uses getfullargspec internally)

With appropriate docs and tests updates, I don't see a problem with adding the feature, though. Docs should note and tests should ensure that this only goes one level deep - if __call__ isn't a real function either, inspect shouldn't try to follow the descriptor chain down the rabbit hole. Anything else runs the risk of infinite recursion in the face of things like "inspect.getargspec(list)".

----------
title: Allow callable objects in inspect.getargspec -> Allow callable objects in inspect.getfullargspec

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:01:27 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 Jul 2011 12:01:27 +0000
Subject: [issue8639] Allow callable objects in inspect.getfullargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1310385687.3.0.862579687059.issue8639@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I can produce a patch w/ tests and documentation for you to review Nick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8639>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:03:43 2011
From: report at bugs.python.org (Peter Eisentraut)
Date: Mon, 11 Jul 2011 12:03:43 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>


New submission from Peter Eisentraut <peter_e at gmx.net>:

The existing documentation index entries for * and ** only point to their use in function definitions but not to their use in function calls.  I was looking for the latter, and it was difficult to find without this.  Here is a small patch to add the additional entries.

----------
assignee: docs at python
components: Documentation
files: python-doc-index-**.patch
keywords: patch
messages: 140113
nosy: docs at python, petere
priority: normal
severity: normal
status: open
title: documentation index entries for * and **
versions: Python 3.3
Added file: http://bugs.python.org/file22619/python-doc-index-**.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:06:46 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 11 Jul 2011 12:06:46 +0000
Subject: [issue12494] subprocess: check_output() doesn't close pipes on error
In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za>
Message-ID: <1310386006.64.0.168003325367.issue12494@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12494>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:10:16 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 11 Jul 2011 12:10:16 +0000
Subject: [issue12517] Large file support on Windows: sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: <1310386216.68.0.119487177563.issue12517@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12517>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:35:44 2011
From: report at bugs.python.org (Eugene Toder)
Date: Mon, 11 Jul 2011 12:35:44 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1310387744.25.0.7217332052.issue5996@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

They are, when there's a most specific metaclass -- the one which is a subclass of all others (described here http://www.python.org/download/releases/2.2.3/descrintro/#metaclasses, implemented here http://hg.python.org/cpython/file/ab162f925761/Objects/typeobject.c#l1956). Since ABCMeta is a subclass of type this holds.

Also, in the original example there's no multiple inheritance at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:53:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Jul 2011 12:53:00 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1310388780.83.0.0886562797449.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I moved my personal sandbox from hg.python.org to bitbucket, so it should be easier for folks to build off the work in progress. (And fixed the typo in Renaud's name - I at least had it right in ACKS. I also reworded the draft attribution text in What's New)

I skimmed Benjamin's comments and basically agree with them. I've marked issue 11816 as a dependency as some of the new tests will be easier to refactor once dis.get_opinfo() is available.

----------
dependencies: +Refactor the dis module to provide better building blocks for bytecode analysis
hgrepos: +40

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Mon Jul 11 14:53:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 12:53:50 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1310388830.56.0.485644559086.issue11435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch to fix links in the 3.2 docs.

----------
Added file: http://bugs.python.org/file22620/docs-source-link-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:01:38 2011
From: report at bugs.python.org (Michael Mulich)
Date: Mon, 11 Jul 2011 13:01:38 +0000
Subject: [issue12532] PyPI server index names with '/' in them
In-Reply-To: <1310389298.77.0.644675423284.issue12532@psf.upfronthosting.co.za>
Message-ID: <1310389298.77.0.644675423284.issue12532@psf.upfronthosting.co.za>


New submission from Michael Mulich <michael.mulich at gmail.com>:

Forward slashes show up in a project's (packaging.pypi.dist.ReleaseList) name when using a crawler (packaging.pypi.simple.Crawler) against, say and Apache index page. The packaging.tests:/pypiserver/foo_bar_baz directory is a perfect example of this type of data, but it isn't used anywhere in the current tests.

If a crawl is run on the index, results will come back with '/' in there name.

The issue was found when I was attempting to use a Crawler against the packaging.tests.pypi_server.PyPIServer in my package's tests.

----------
assignee: tarek
components: Distutils2
files: test_name.py
messages: 140117
nosy: alexis, eric.araujo, michael.mulich, tarek
priority: normal
severity: normal
status: open
title: PyPI server index names with '/' in them
versions: Python 3.3
Added file: http://bugs.python.org/file22621/test_name.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12532>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:02:03 2011
From: report at bugs.python.org (Michael Mulich)
Date: Mon, 11 Jul 2011 13:02:03 +0000
Subject: [issue12532] PyPI server index names with '/' in them
In-Reply-To: <1310389298.77.0.644675423284.issue12532@psf.upfronthosting.co.za>
Message-ID: <1310389323.17.0.230069467528.issue12532@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12532>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:04:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Jul 2011 13:04:39 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1310389479.01.0.261657616922.issue5996@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:05:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 13:05:13 +0000
Subject: [issue12518] In string.Template it's impossible to transform
	delimiter in the derived class
In-Reply-To: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>
Message-ID: <1310389513.04.0.463192806129.issue12518@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See 629200d880ea for answers.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12518>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:06:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 13:06:17 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1310389577.83.0.295083632383.issue12449@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What do you mean with disabled?  There is a bdist_wininst command in packaging.  Use ?pysetup run bdist_wininst? to call it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:07:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 13:07:35 +0000
Subject: [issue12452] deprecation process in plistlib
In-Reply-To: <1309444761.1.0.605266895542.issue12452@psf.upfronthosting.co.za>
Message-ID: <1310389655.44.0.197390141425.issue12452@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let?s keep one report per bug.  Please open another one for sysconfig, with Mac and distutils maintainers as nosy.

----------
nosy: +eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
title: reuse plistlib in sysconfig; deprecation process in plistlib -> deprecation process in plistlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12452>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:08:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 13:08:11 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310389691.96.0.807765238839.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me clarify my position: I think there is a bug in lib2to3 that should be fixed, after what the refleak would go.  (I?ll report it soon if nobody does it before.)  If Benjamin rejects the bug, then I?ll agree with the monkey-patch.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:12:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 13:12:57 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310389977.7.0.363778545339.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> In Distributions.get_reinitialized_command should the
> reinitialization of the subcommands also get passed the kwargs?
Yes, the kwargs need to be passed all the way.

> Unfortunately my understanding of the (sub)command flow is not rock
> solid.
Some methods on the command classes are just convenience wrappers for methods on the distribution object.  That?s why I propose here that the real work is done in Distribution.get_reinitialized_command, and that Command.get_reinitialized_command just delegates.

> What are your thoughts on an effective test for this?
Create a command obj with some options.  Call get_reinitialized_command.  Check that its options have the default values, not the values set on the first command obj.

Do the same thing a second time, this time with some kwargs.  Check they?re set on the resulting command obj.

See also three comments about style on http://bugs.python.org/review/8668/diff2/2845:3011/7845

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:13:52 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Jul 2011 13:13:52 +0000
Subject: [issue12518] In string.Template it's impossible to transform
	delimiter in the derived class
In-Reply-To: <1310085409.68.0.478281072881.issue12518@psf.upfronthosting.co.za>
Message-ID: <1310390032.04.0.444967835105.issue12518@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I don't know that anybody relies on the current behavior and computers are now a bazillion times faster than they were in 2004, so who needs that micro optimization any more?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12518>
_______________________________________

From report at bugs.python.org  Mon Jul 11 15:58:39 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Mon, 11 Jul 2011 13:58:39 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1310392719.49.0.613568990362.issue12449@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

I was having a separate difficulty with bdist. Apparently -m packaging.run and pysetup3 run don't perform identically, but that isn't relevant for this bug.

Regarding bdist, I got bdist_wininst to work but I had to modify the code in place, it did not work by default. It also creates an exe installer, not an MSI.

bdist_msi is not set as a valid command to run inside the commands package __init__.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Mon Jul 11 16:12:10 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Mon, 11 Jul 2011 14:12:10 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310393530.56.0.655680180217.issue12344@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

> See also three comments about style on http://bugs.python.org/review/8668/diff2/2845:3011/7845

I'm not sure I follow? The patch I attached does not violate the style guidelines that you indicate in the comments. The only failing I see is that get_reinitialized_command inside cmd.py does not have a doc string. I was following the path of minimal change, but I will be happy to add one.


Unless I am misunderstanding something about the other style comments I will work up another version with subcommand kwargs, docstring, and tests.

Thanks again ?ric

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Mon Jul 11 16:32:24 2011
From: report at bugs.python.org (=?utf-8?q?Kristoffer_Grundstr=C3=B6m?=)
Date: Mon, 11 Jul 2011 14:32:24 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>


New submission from Kristoffer Grundstr?m <kristoffer.grundstrom1983 at gmail.com>:

I went to the wiki of Imprudence Viewer & then I went to the Compiling-part. Then I downloaded latest code from git. I installed everything needed. Then I went into Desktop/imprudence/linden/indra & wrote python develop.py & that resulted in this: http://pastebin.mandriva.com/23157

I then tried to import using the interpreter, but still I got the same issue.

I then uninstalled python-celementtree & ran python develop.py & then everything went on OK.

----------
components: Interpreter Core
messages: 140126
nosy: Kristoffer.Grundstr?m
priority: normal
severity: normal
status: open
title: python-celementtree prevents me from running python develop.py to compile Imprudence Viewer
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Mon Jul 11 16:35:31 2011
From: report at bugs.python.org (=?utf-8?q?Kristoffer_Grundstr=C3=B6m?=)
Date: Mon, 11 Jul 2011 14:35:31 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310394931.29.0.194663944819.issue12533@psf.upfronthosting.co.za>


Kristoffer Grundstr?m <kristoffer.grundstrom1983 at gmail.com> added the comment:

This is valid in Mageia, a fork of Mandriva.
Using 2.6.38.8-desktop-4.mga as kernel.
Arch is x86_64

The link to the imprudence wiki is here:

http://wiki.kokuaviewer.org/wiki/Imprudence:Compiling

Get the latest code for Imprudence here: git clone git://github.com/imprudence/imprudence.git

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:17:18 2011
From: report at bugs.python.org (Michael Mulich)
Date: Mon, 11 Jul 2011 15:17:18 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310397438.69.0.52541021819.issue8668@psf.upfronthosting.co.za>


Michael Mulich <michael.mulich at gmail.com> added the comment:

After looking over the use cases, these are my findings and questions:

* Cases 2, 3, 5 and 6 are strongly related. I'd suggest you condense them into a single use case. I agree with case 2 and 6 most, but have questions:
** Why wouldn't one simply use a virtualenv? -- Case 5 touches on this topic, but if we are installing in-place, who cares if can place a development package in the global site-packages directory?
** After the package has been installed in-place (using the develop command), how does one identify it as an in development project (or in development mode)? -- Case 3 and 6 touch on this topic (case 3 is a little vague at this time), but doesn't explain what type of action is intended. So if we install in-place (aka, develop), how does the python interpreter find the package? Are we using PYTHONPATH at this point (which would be contradict a requirement in  case 6)?

* Case 4 is a be unclear. Is Carl, the actor, pulling unreleased remote changes (hg pull --update) for these mercurial server plugins then running the develop command on them? 

* Case 1 is good and very clear, but I'd consider it a feature rather than required. Perhaps it should not be focused on first (priority). Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:28:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:28:40 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1310398120.1.0.897194110833.issue12449@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Apparently -m packaging.run and pysetup3 run don't perform
> identically, but that isn't relevant for this bug.
That?s very surprising, given that they have the same one-line code.  Please file that bug.

> Regarding bdist, I got bdist_wininst to work but I had to modify the
> code in place, it did not work by default.
Can you report that too, if there is no existing bug?  (Maybe it?s #10945 or another one.)

> It also creates an exe installer, not an MSI.
Why would you think it creates an MSI?  bdist_wininst is not bdist_msi.

> bdist_msi is not set as a valid command to run inside the commands
> package __init__.py.
Is it a problem?  In distutils too, bdist_msi is not registered in command.__init__, as it can?t run on non-Windows, but the bdist command knows that it exists and can run it.  IOW, there are two registries of bdist commands: in command.__init__, which is used by --help-commands and others, and in bdist.  In distutils, calling bdist --formats=msi or directly bdist_msi works (on Windows); if it doesn?t work with packaging, this is another bug to report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:29:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:29:58 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310398198.27.0.179889977974.issue12344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The patch I attached does not violate the style guidelines that you
> indicate in the comments.

Then it?s good.  I was hurrying for my train, so I didn?t check your patch but wanted to reference my comments somewhere before I forgot them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:30:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:30:25 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1310398225.15.0.935420480637.issue10403@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/issue10403>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:34:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:34:34 +0000
Subject: [issue12420] distutils tests fail if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1310398474.24.0.731690788951.issue12420@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry, I don?t want to monkey-patch find_executable during tests.  We want the tests to work with the real code, with the same behavior and errors as real setup.py calls.  If a test does not work with python -E, then it should be skipped.

(Implementation idea:
  skip_if_empty_env = unittest.skipUnless(
      os.environ, 'test cannot run with an empty environment')
using sys.flags is not possible due to backward compatibility policy)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12420>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:35:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:35:20 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1310398520.98.0.730716081033.issue3561@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/issue3561>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:35:34 2011
From: report at bugs.python.org (michael mulich)
Date: Mon, 11 Jul 2011 15:35:34 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1310125090.05.0.40593876453.issue12279@psf.upfronthosting.co.za>
Message-ID: <CACvZ6pzEcNb01Wft5+yrX=rCXUMys-uOJd7yv1yz9hCXnUEKfA@mail.gmail.com>


michael mulich <michael.mulich at gmail.com> added the comment:

We have to generate a RECORD, otherwise resource lookups in
development and testing modes will fail or at least should fail.

Yes, but that's not all.

> 4) don?t add a build_distinfo command, just run install_distinfo to the build dir from the test and develop commands

The action needs to be called with an install, develop or test
context, so I think item four is our best option.

----------
nosy: +michael.mulich2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:39:07 2011
From: report at bugs.python.org (michael mulich)
Date: Mon, 11 Jul 2011 15:39:07 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <CACvZ6pzEcNb01Wft5+yrX=rCXUMys-uOJd7yv1yz9hCXnUEKfA@mail.gmail.com>
Message-ID: <CACvZ6pzEgU6zPaWwBOH+KfzMCH-J2xV9JbTA3DVXYnUbb0Mf-Q@mail.gmail.com>


michael mulich <michael.mulich at gmail.com> added the comment:

Gmail decided to strip the quotes... Grr...

  > So, what do we do?
  > 1) don?t generate RECORD at all ? invalid PEP 376
We have to generate a RECORD, otherwise resource lookups in
development and testing modes will fail or at least should fail.

  > 2) generate RECORD with paths to the files in the build dir
Yes, but that's not all.

  > 4) don?t add a build_distinfo command, just run install_distinfo
to the build dir from the test and develop commands

The action needs to be called with an install, develop or test
context, so I think item four is our best option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:42:21 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Jul 2011 15:42:21 +0000
Subject: [issue11510] Peephole breaks set unpacking
In-Reply-To: <1300140363.98.0.218128326427.issue11510@psf.upfronthosting.co.za>
Message-ID: <1310398941.6.0.0639114285563.issue11510@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/issue11510>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:43:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:43:11 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1310398991.29.0.391352912359.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(It was probably the Roundup quotes bug.)

> The action needs to be called with an install, develop or test
> context, so I think item four is our best option.

What do you mean with context?  Wouldn?t all three commands just make install_distinfo generate files in the build dir?

I think that option 4 is the most inelegant, and would be sad to see it win.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:48:42 2011
From: report at bugs.python.org (Michael Mulich)
Date: Mon, 11 Jul 2011 15:48:42 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1310399322.78.0.44173803918.issue12279@psf.upfronthosting.co.za>


Changes by Michael Mulich <michael.mulich at gmail.com>:


----------
nosy:  -michael.mulich2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:50:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:50:02 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1310399402.42.0.701647608921.issue11561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your work on this.  I made some minor comments on Rietveld (you should get an email), waiting for the real import experts to comment on the meat of the patch.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11561>
_______________________________________

From report at bugs.python.org  Mon Jul 11 17:53:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 15:53:57 +0000
Subject: [issue12418] python should inherit the library search path from the
	compiler for stdlib extensions
In-Reply-To: <1309176139.38.0.221668771682.issue12418@psf.upfronthosting.co.za>
Message-ID: <1310399637.61.0.0156334916797.issue12418@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> But maybe it would be enough to special case GCC as a unix compiler?
> At least there are already autoconf checks trying to detect gcc.

Yes, we could try that.  Steve, would you like to propose a patch?

----------
nosy: +barry
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12418>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:02:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 16:02:34 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310400154.82.0.295363892791.issue12533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

setuptools bug are reported to these trackers: http://bugs.python.org/setuptools/ and https://bitbucket.org/tarek/distribute/issues

If a setuptools bugs comes from the underlying standard module, distutils, then this bug tracker is the right place, otherwise we can?t do anything.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:05:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 16:05:29 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1310400329.18.0.644108924869.issue12434@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you think the docstrings and error messages should be improved as well as the docs?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:07:23 2011
From: report at bugs.python.org (=?utf-8?q?Kristoffer_Grundstr=C3=B6m?=)
Date: Mon, 11 Jul 2011 16:07:23 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310400443.1.0.430868240315.issue12533@psf.upfronthosting.co.za>


Kristoffer Grundstr?m <kristoffer.grundstrom1983 at gmail.com> added the comment:

Well, I didn't know what do choose when I reported.
What more info do you need to help me put it in the right place?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:10:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 16:10:53 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310400653.33.0.744817961097.issue12533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If there is a bug with distutils, xml.etree or CPython, then we need instructions on how to reproduce it.

If the bug can only happen with third-party ElementTree release, setuptools or Imprudence, then I?ll suggest you to go to the setuptools bug trackers (there is a fork, so there are two trackers) with your report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:13:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 16:13:06 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1310400786.07.0.8062834225.issue12436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Goal #1: set up Python
I believe http://docs.python.org/dev/using/ covers this.

> Goal #2: prepare a text editor
This is missing from our docs.  (My first thought was that it was out of scope, but for complete beginners, it would be nice to give a few pointers.)

> Goal #3: practice starting and exiting Python
The tutorial has one page about that.

> Goal #4: practice navigating the computer from a command prompt
Out of scope?

> Goal #5: practice running Python code from a file
This is probably in the tutorial or using docs, I have to check.

> Goal #6: get dependencies installed for the Saturday projects
This used to be non-standard, but now that we have packaging and pysetup, I translate this item to a doc bug: Explain how to use pysetup to get dependencies (in using, I think).

> Goal #7: start learning Python!
> Goal #8: Checkoff
Nothing to add, IMO.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:14:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 16:14:50 +0000
Subject: [issue12379] build outside source fail in head
In-Reply-To: <1308600053.87.0.881101721168.issue12379@psf.upfronthosting.co.za>
Message-ID: <1310400890.82.0.992341587846.issue12379@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR:
> Out-of-tree configure also fails because of missing .o files.
The solution is to remove the .o files.  Then one can run configure in a subdir, and later make.  This allows me to build in shared mode in a subdir, and have a regular build in the top level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12379>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:20:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 16:20:02 +0000
Subject: [issue12509] test_gdb fails on debug build when builddir != srcdir
In-Reply-To: <1309994715.39.0.391727043164.issue12509@psf.upfronthosting.co.za>
Message-ID: <1310401202.03.0.245999707236.issue12509@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch LGTM.

----------
components: +Tests -None
nosy: +eric.araujo
versions: +Python 2.7, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12509>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:20:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Jul 2011 16:20:19 +0000
Subject: [issue12509] test_gdb fails on debug build when builddir != srcdir
In-Reply-To: <1309994715.39.0.391727043164.issue12509@psf.upfronthosting.co.za>
Message-ID: <1310401219.13.0.914507625333.issue12509@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

About 2.7: Can you please test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12509>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:21:53 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 11 Jul 2011 16:21:53 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1310401313.75.0.929186540421.issue11561@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11561>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:35:56 2011
From: report at bugs.python.org (Michael Mulich)
Date: Mon, 11 Jul 2011 16:35:56 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1310398991.29.0.391352912359.issue12279@psf.upfronthosting.co.za>
Message-ID: <CACvZ6pxREHk1d_9i0FEy+9F+TsYTJ1iB6Y_1HKue7Ab2oHnt0w@mail.gmail.com>


Michael Mulich <michael.mulich at gmail.com> added the comment:

On Mon, Jul 11, 2011 at 11:43 AM, ?ric Araujo <report at bugs.python.org> wrote:
 > What do you mean with context? ?Wouldn?t all three commands just
make install_distinfo generate files in the build dir?

Right, my context comment is invalid.

 > I think that option 4 is the most inelegant, and would be sad to see it win.
Ok... I forgot that we now have this RESOURCES file, which makes
leaving out the RECORD file less important, but still invalid based on
PEP 376.

So if we include the RECORD file (point number 2) without the checksum
and size (two columns in the RECORD csv format), we will still be
PEP376 valid (maybe?), but the file verification information will be
missing. And we don't really want this information because if we edit
a file, the checksum and size will be incorrect anyhow. This missing
information is not important when using the develop or test commands,
because we are running the commands on a trusted local copy. What are
the consequences of not writing the checksum or size to the RECORD
file? And does that solve the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:43:18 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 11 Jul 2011 16:43:18 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310402598.56.0.561017720307.issue8668@psf.upfronthosting.co.za>


Carl Meyer <carl at dirtcircle.com> added the comment:

Can someone post a link here to the page of use cases that Michael just reviewed? I think the link came through on the Fellowship mailing list, but I'm not quickly finding it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:55:42 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Mon, 11 Jul 2011 16:55:42 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310403342.21.0.669586514009.issue8668@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Carl, I believe that's this one: http://wiki.python.org/moin/UsecasesOfDevelop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:56:28 2011
From: report at bugs.python.org (Aaron Stevens)
Date: Mon, 11 Jul 2011 16:56:28 +0000
Subject: [issue12534] Tkinter doesn't support property attributes
In-Reply-To: <1310403388.57.0.795196885284.issue12534@psf.upfronthosting.co.za>
Message-ID: <1310403388.57.0.795196885284.issue12534@psf.upfronthosting.co.za>


New submission from Aaron Stevens <aaron.stevens at molex.com>:

When using Tkinter in Python 2.6.6, it is impossible to use the new-style properties, as the base classes (Misc, Pack, Place, and Grid) do not use the new style classes.

It is easily fixed by changing the class declarations, i.e.:
  class Misc:
 becomes
  class Misc(object):

----------
components: Tkinter
messages: 140148
nosy: bheklilr
priority: normal
severity: normal
status: open
title: Tkinter doesn't support property attributes
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12534>
_______________________________________

From report at bugs.python.org  Mon Jul 11 18:57:59 2011
From: report at bugs.python.org (Aaron Stevens)
Date: Mon, 11 Jul 2011 16:57:59 +0000
Subject: [issue12534] Tkinter doesn't support property attributes
In-Reply-To: <1310403388.57.0.795196885284.issue12534@psf.upfronthosting.co.za>
Message-ID: <1310403479.96.0.0798301625695.issue12534@psf.upfronthosting.co.za>


Aaron Stevens <aaron.stevens at molex.com> added the comment:

I forgot add that this is a problem only when inheriting from a Tkinter widget, such as a Frame.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12534>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:05:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 17:05:27 +0000
Subject: [issue12534] Tkinter doesn't support property attributes
In-Reply-To: <1310403388.57.0.795196885284.issue12534@psf.upfronthosting.co.za>
Message-ID: <1310403927.27.0.114286446285.issue12534@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is not a bug fix, but a feature request.  In Python3 the classes are of course new style.  So there's nothing to do here, sorry.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12534>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:14:04 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 11 Jul 2011 17:14:04 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1310397438.69.0.52541021819.issue8668@psf.upfronthosting.co.za>
Message-ID: <4E1B309B.6000508@dirtcircle.com>


Carl Meyer <carl at dirtcircle.com> added the comment:

On 07/11/2011 09:17 AM, Michael Mulich wrote:
> * Cases 2, 3, 5 and 6 are strongly related. I'd suggest you condense them into a single use case. I agree with case 2 and 6 most, but have questions:
> ** Why wouldn't one simply use a virtualenv? 

I don't know. I don't consider case 3 useful, because I don't consider
"I don't want to use a virtualenv" (without some clearer technical
justification) to be a prejudice the develop feature needs to support;
especially if supporting it essentially means re-implementing a
less-capable version of virtualenv within the develop command.

> -- Case 5 touches on this topic, but if we are installing in-place, who cares if can place a development package in the global site-packages directory?

Several of these stories make the assumption that even the "in-place"
installation will require placing a file in the installation location (a
.pth file, if we follow the current setuptools implementation strategy).
I think this is probably true, given the requirements in case 6 (which I
agree with). So if you want an in-place install that's globally
accessible, you'd need write access to global site-packages.

> ** After the package has been installed in-place (using the develop command), how does one identify it as an in development project (or in development mode)? -- Case 3 and 6 touch on this topic (case 3 is a little vague at this time), but doesn't explain what type of action is intended. So if we install in-place (aka, develop), how does the python interpreter find the package? Are we using PYTHONPATH at this point (which would be contradict a requirement in  case 6)?

These use cases (probably intentionally) don't touch on specific
implementation strategies, but as I mentioned there's an implicit
assumption that a .pth file is the most likely strategy.

> * Case 4 is a be unclear. Is Carl, the actor, pulling unreleased remote changes (hg pull --update) for these mercurial server plugins then running the develop command on them? 

Right, although the requirement for that story is that you don't have to
re-run the develop command after every pull; if you develop-install it
once, you can simply pull more code changes in and they'll immediately
be available. I've added a line to that story to make it more clear.

> * Case 1 is good and very clear, but I'd consider it a feature rather than required. Perhaps it should not be focused on first (priority). Thoughts?

I agree that's a second-level feature (or, perhaps more accurately, a
bug in the existing setuptools feature that I was hoping could be
addressed in the d2 version), not a primary requirement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:32:08 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 11 Jul 2011 17:32:08 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1310405528.55.0.590514791871.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The new regex imlementation is hosted here: https://code.google.com/p/mrab-regex-hg/

The span of m['a_thing'] is m.span('a_thing'), if that helps.

The named groups are listed on the pattern object, which can be accessed via m.re:

>>> m.re
<_regex.Pattern object at 0x0161DE30>
>>> m.re.groupindex
{'another_thing': 3, 'a_thing': 1}

so you can use that to create a reverse dict to go from the index to the name or None. (Perhaps the pattern object should have such a .group_name attribute.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:33:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 17:33:03 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Consider the following traceback:

Traceback (most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in __getattr__
    return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
    self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in replace_header
    print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in __getattr__
    self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'


The first traceback, which is supposed to be the "primary" error, gives
no indication of where the problem occured.  It starts with a fairly
deeply nested call.  The second traceback does show the line where the
error occured in the except statement, but you have to read the lines
above it to find the line that actually triggered the original
traceback.

I think it would be much better if either the full traceback were
given for the first traceback, or for both of them.  I realize
that the short traceback for the first traceback is how things
have "traditionally" worked when exceptions are caught, but as
evidenced by issue 1553375 this is often not the desired behavior
even before the existence of chained exceptions.

----------
components: Interpreter Core
messages: 140153
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Chained tracebacks are confusing because the first traceback is minimal
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:38:26 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Jul 2011 17:38:26 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1310405906.31.0.227381923336.issue2636@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:40:50 2011
From: report at bugs.python.org (Alec Koumjian)
Date: Mon, 11 Jul 2011 17:40:50 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1310406050.55.0.59410277661.issue2636@psf.upfronthosting.co.za>


Alec Koumjian <akoumjian at gmail.com> added the comment:

Thanks, Matthew. I did not realize I could access either of those. I should be able to build a helper function now to do what I want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:42:41 2011
From: report at bugs.python.org (Collin Winter)
Date: Mon, 11 Jul 2011 17:42:41 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1310406161.91.0.254849788707.issue2636@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy:  -collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:46:50 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 11 Jul 2011 17:46:50 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1310406410.22.0.710076319061.issue2636@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:47:00 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 11 Jul 2011 17:47:00 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310406420.66.0.635654170347.issue12535@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Mon Jul 11 19:58:21 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 11 Jul 2011 17:58:21 +0000
Subject: [issue12536] lib2to3 BaseFix class creates un-needed loggers leading
	to refleaks
In-Reply-To: <1310407101.06.0.821103833142.issue12536@psf.upfronthosting.co.za>
Message-ID: <1310407101.06.0.821103833142.issue12536@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

See #12167 for background.

The BaseFix class creates a logger named with the filename when the set_filename method is called. This logger appears to never be used, but since set_filename could be called any number of times and loggers are effectively singletons and not garbage collected, this could lead to refleaks and unbounded memory usage for no benefit.

It's possible to output contextual information about a file being worked on without needing to create a logger with the filename.

I'm proposing that the references to the logger in BaseFix be removed, as the logger isn't used anyway, and the test suite runs without failures when the references are removed. This will allow progress on #12167.

----------
components: 2to3 (2.x to 3.0 conversion tool), Library (Lib)
keywords: easy
messages: 140155
nosy: benjamin.peterson, eric.araujo, vinay.sajip
priority: normal
severity: normal
status: open
title: lib2to3 BaseFix class creates un-needed loggers leading to refleaks
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12536>
_______________________________________

From report at bugs.python.org  Mon Jul 11 20:00:01 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 11 Jul 2011 18:00:01 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310407201.71.0.000155302717281.issue12167@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've created #12536 to cover the lib2to3 issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Mon Jul 11 20:31:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 18:31:15 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The mailbox module has a method _become_message that copies attributes from an object that is an email.message.Message subclass to the calling object (which is also a subclass of email.message.Message).  This method is very fragile in the face of any changes to the email.message.Message attribute set.

Instead it would be better to decouple the mailbox and email modules by copying *all* __dict__ attributes from the source message to the new object, and then rewrite the _explain_to methods to not only convert the 'special attributes' to the correct format for the new subclass, but also delete any leftover "special" attributes.

----------
components: Library (Lib)
keywords: easy
messages: 140157
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: mailbox's _become_message is very fragile
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12537>
_______________________________________

From report at bugs.python.org  Mon Jul 11 20:50:18 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Mon, 11 Jul 2011 18:50:18 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1310410218.4.0.956631418663.issue12537@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


----------
nosy: +thomas.holmes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12537>
_______________________________________

From report at bugs.python.org  Mon Jul 11 21:43:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 19:43:29 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310413409.8.0.0382471212455.issue12535@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the reason the chained tracebacks look backward to me is twofold: I'm used to the last one in the list being the *only* one I get (in python2), and the last one in the list is often the one I want to deal with first.  This is especially true if my try/except is transforming the more-specific-but-not-application-meaningful exception into one that is meaningful for the application.

So another possibility would be to reverse the order in which the tracebacks are printed, and instead of saying "during the handling of the above exception...", we'd say "this exception occurred during the handling of the following exception:".  Doing this would probably greatly reduce the desire for a way to suppress the traceback chaining.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Mon Jul 11 21:46:47 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 11 Jul 2011 19:46:47 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310413607.21.0.137684775598.issue12535@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

There _is_ no full traceback for the first exception. It stops as soon as it's handled.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Mon Jul 11 21:57:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 19:57:30 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310414250.33.0.992578190982.issue12535@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

One can argue that it is necessary to read the traceback in reverse order, so that reading the chain in reverse order is a logical extension of that.  So I guess I have no serious objection to this being rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Mon Jul 11 22:26:03 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 11 Jul 2011 20:26:03 +0000
Subject: [issue12538] Extending int class
In-Reply-To: <1310415963.68.0.740269303687.issue12538@psf.upfronthosting.co.za>
Message-ID: <1310415963.68.0.740269303687.issue12538@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

I'm having trouble subclassing the int type and I think this behavior is a bug... (Python 3.2)

>>> class One(int):
	def __init__(self):
		super().__init__(1)

>>> one = One()
>>> one + 2
2
>>> one == 0
True

I know `int` objects are immutable but my `One` class should be mutable... and why it doesn't raise an error?

That gives the same result on Python 2.7 using super properly.

Also, if that's not a bug, how it should be done to achieve "one + 2 == 3" without creating another attribute.

Things I also tried:
    self.real = 1  #readonly attribute error
    int.__init__(self, 1)  #same behavior

I Couldn't find any related issues... sorry if it's repeated.

----------
components: Interpreter Core
messages: 140161
nosy: JBernardo
priority: normal
severity: normal
status: open
title: Extending int class
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12538>
_______________________________________

From report at bugs.python.org  Mon Jul 11 23:07:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Jul 2011 21:07:53 +0000
Subject: [issue12538] Extending int class
In-Reply-To: <1310415963.68.0.740269303687.issue12538@psf.upfronthosting.co.za>
Message-ID: <1310418473.76.0.0414487337635.issue12538@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

To set the value of an immutable type you must use the __new__ method.  By the time __init__ is called the value has already be established, and in the case of int it defaults to 0.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12538>
_______________________________________

From report at bugs.python.org  Mon Jul 11 23:11:23 2011
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Mar=C3=ADa_Ruiz_Aguilera?=)
Date: Mon, 11 Jul 2011 21:11:23 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1310418683.9.0.445001990686.issue12537@psf.upfronthosting.co.za>


Jos? Mar?a Ruiz Aguilera <josemariaruiz at gmail.com> added the comment:

Hi, I will be working on this issue. This is the first time I will work on a issue in Python so please patient.

----------
nosy: +josemaria

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12537>
_______________________________________

From report at bugs.python.org  Mon Jul 11 23:57:36 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Jul 2011 21:57:36 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1310399402.42.0.701647608921.issue11561@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W5a_cJmcpBacy5ZCcwQxs66P7kmPSZcXf=ypePKjN_foQ@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

Which I have not forgotten about. Just waiting until I have the time to get
to this.

On Mon, Jul 11, 2011 at 08:50, ??ric Araujo <report at bugs.python.org> wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> Thanks for your work on this.  I made some minor comments on Rietveld (you
> should get an email), waiting for the real import experts to comment on the
> meat of the patch.
>
> ----------
> nosy: +eric.araujo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11561>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22622/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11561>
_______________________________________
-------------- next part --------------
Which I have not forgotten about. Just waiting until I have the time to get to this.<br><br><div class="gmail_quote">On Mon, Jul 11, 2011 at 08:50, ??ric Araujo <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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Thanks for your work on this. ??I made some minor comments on Rietveld (you should get an email), waiting for the real import experts to comment on the meat of the patch.<br>
<br>
----------<br>
nosy: +eric.araujo<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/issue11561" target="_blank">http://bugs.python.org/issue11561</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Jul 12 01:06:22 2011
From: report at bugs.python.org (mokrates)
Date: Mon, 11 Jul 2011 23:06:22 +0000
Subject: [issue12539] multiprocessing.Event.wait(n) doesn't time out properly
In-Reply-To: <1310425582.71.0.534887879142.issue12539@psf.upfronthosting.co.za>
Message-ID: <1310425582.71.0.534887879142.issue12539@psf.upfronthosting.co.za>


New submission from mokrates <mmolle at gmx.net>:

Following is my problem:
I have two processes, connected via multiprocessing.Event
The one waits for the other with .wait(300). After 300 seconds it should look if there's work, even if it has not been awoken by the other process.
So. This runs on my Laptop, and when I fold it shut, sending it to suspend, and open it again, lets say, 10 minutes later (which are 600 seconds), then the .wait()-timeout has already gone. I would assume, cause it's a /timeout/ that it should then fire ASAP, but it fires never. The worker process is just frozen and has to be awoken by .set()ing the Event.

I workarounded it by creating another thread, which uses time.sleep(300) instead of multiprocessing.Event.wait(300) to wait 300 seconds and some glue to put it all together.

some stats:
me at mybox:~$ python2.7
Python 2.7.1+ (default, Apr 20 2011, 22:33:39) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
me at mybox:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux testing (wheezy)
Release:	testing
Codename:	wheezy

----------
messages: 140165
nosy: mokrates
priority: normal
severity: normal
status: open
title: multiprocessing.Event.wait(n) doesn't time out properly
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12539>
_______________________________________

From report at bugs.python.org  Tue Jul 12 03:14:45 2011
From: report at bugs.python.org (Michael Mulich)
Date: Tue, 12 Jul 2011 01:14:45 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <4E1B309B.6000508@dirtcircle.com>
Message-ID: <CACvZ6pwiWrKx5s_wiNNHpGNP3o0hF7ZdnhAAZEZHNDYPVG+uag@mail.gmail.com>


Michael Mulich <michael.mulich at gmail.com> added the comment:

On Mon, Jul 11, 2011 at 1:14 PM, Carl Meyer <report at bugs.python.org> wrote:
>> * Cases 2, 3, 5 and 6 are strongly related.
> I don't know. I don't consider case 3 useful, because I don't consider
> "I don't want to use a virtualenv" (without some clearer technical
> justification) to be a prejudice the develop feature needs to support;
> especially if supporting it essentially means re-implementing a
> less-capable version of virtualenv within the develop command.

I think your later comments about the use of .pth files solves the
issue for all four cases. We simply make reference in a .pth file in
one of the approved site locations. For example, in case two we would
write a .pth entry to site.USER_SITE. Sound about right?

>> -- Case 5
> Several of these stories make the assumption that even the "in-place"
> installation will require placing a file in the installation location (a
> .pth file, if we follow the current setuptools implementation strategy).
> I think this is probably true, given the requirements in case 6 (which I
> agree with). So if you want an in-place install that's globally
> accessible, you'd need write access to global site-packages.

Basically write the .pth entry for the build to a site (the standard
lib module) recognized location.

>> * Case 4
> Right, although the requirement for that story is that you don't have to
> re-run the develop command after every pull; if you develop-install it
> once, you can simply pull more code changes in and they'll immediately
> be available. I've added a line to that story to make it more clear.

Ah, this case impacts the decision being made in issue 12279
(http://bugs.python.org/issue12279). The decision is to write a RECORD
file or not. We wouldn't write a RECORD if you want to be able to
update without rerunning the develop command. But this would be
invalid based on PEP 376 guidelines. Please post your thoughts about
this in that issue.

The wiki page has been edited to note what the develop command will
write to the file system. I'll restate it here as well...

The develop command writes three pieces of information to the filesystem:
 1. It calls upon the build action(s) to build the package relative to
the package's root directory.
 2. It calls the [build|install]_distinfo action to write the
.dist-info metadata inside the build directory. (see also Issue 12279)
 3. It adds the build directory's path to a .pth file.

Thanks Carl

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 03:35:09 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Tue, 12 Jul 2011 01:35:09 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310434509.88.0.967215401243.issue4376@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Added unit test to reproduce the issue (covers both big endian and little endian structures so _other_endian function is hit on any machine).

Test currently fails without fix and passes with proposed fix in place.

----------
keywords: +patch
nosy: +vladris
Added file: http://bugs.python.org/file22623/issue4376_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Tue Jul 12 03:41:02 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 12 Jul 2011 01:41:02 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310434862.15.0.15212520971.issue12344@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

I have added a test and made some additional modifications. I had to modify the very simple MyCmd object in test_command_cmd.py so that it would have some user options with default values and support finalization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Tue Jul 12 03:41:36 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 12 Jul 2011 01:41:36 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310434896.34.0.556500369246.issue12344@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file22624/7c61eba07f3f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Tue Jul 12 03:43:08 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 12 Jul 2011 01:43:08 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310434988.84.0.249990094737.issue12344@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Removed file: http://bugs.python.org/file22624/7c61eba07f3f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Tue Jul 12 03:43:26 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 12 Jul 2011 01:43:26 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1310435006.39.0.773799478688.issue12344@psf.upfronthosting.co.za>


Changes by Thomas Holmes <thomas at devminded.com>:


Added file: http://bugs.python.org/file22625/115c0c10b3ba.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12344>
_______________________________________

From report at bugs.python.org  Tue Jul 12 03:44:12 2011
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 12 Jul 2011 01:44:12 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1310435052.08.0.279238638799.issue12279@psf.upfronthosting.co.za>


Carl Meyer <carl at dirtcircle.com> added the comment:

You guys are more familiar with the codebase than I am, but it seems to me that the RECORD file should clearly either be not present or empty when metadata has been built but not yet installed. I don't really think the "invalid PEP 376" issue is a problem: PEP 376 describes the metadata for installed distributions; it has nothing to say about built metadata for a distribution which has not yet been installed.

For purposes of the develop command, if a pth file is used to implement develop, then ideally when develop is run a RECORD file would be added containing only the path to that pth file, as thats the only file that has actually been installed (and the only one that should be removed if the develop-installed package is uninstalled).

----------
nosy: +carljm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Tue Jul 12 04:09:24 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 12 Jul 2011 02:09:24 +0000
Subject: [issue12485] textwrap.wrap: new argument for more pleasing output
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1310436564.91.0.839005353014.issue12485@psf.upfronthosting.co.za>


Tyler Romeo <tylerromeo at gmail.com> added the comment:

OK, sorry to get back so late, but here's the updated patch without xrange. I saw the version change but forgot that I used xrange in the function (old habits I guess).

----------
Added file: http://bugs.python.org/file22626/textwrap.py-beautiful-2011-07-11_22-01-31_r71296+.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12485>
_______________________________________

From report at bugs.python.org  Tue Jul 12 04:09:45 2011
From: report at bugs.python.org (Tyler Romeo)
Date: Tue, 12 Jul 2011 02:09:45 +0000
Subject: [issue12485] textwrap.wrap: new argument for more pleasing output
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1310436585.6.0.970911467277.issue12485@psf.upfronthosting.co.za>


Changes by Tyler Romeo <tylerromeo at gmail.com>:


Removed file: http://bugs.python.org/file22573/textwrap.py-new-algorithm-2011-07-04_22-45-53_r71219+.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12485>
_______________________________________

From report at bugs.python.org  Tue Jul 12 04:34:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Jul 2011 02:34:55 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1310438095.33.0.769778758857.issue12434@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My original suggestion is a minimal change suggestion. I do not have much opinion on what the maximum change 'should' be.

It would obviously be nice from a user viewpoint if the error message were backported to say "unicode argument expected, got 'str'". Then the note change might not be needed. But I do not know if the particular message is an accident or part of a policy of not fully backporting the code (to aid future patching?), or whether there are other messages that would need the same treatment.

The module docstring shown by help(io) does not have the terminology note to be augmented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Tue Jul 12 04:50:20 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Tue, 12 Jul 2011 02:50:20 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310439020.75.0.664665366285.issue4376@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Also added diff for fix:

- Implemented proposed issubclass(typ, Structure) solution
- Refactored _other_endian function because we used to getattr, catch exception, then check if type is array/structure. I believe exception throwing should not be on normal code path so I replaced try-except with a check for hasattr
- Removed a unittest which becomes deprecated with this fix (unittest asserts getting _other_endian for nested struct raises exception which is no longer the case)

----------
Added file: http://bugs.python.org/file22627/issue4376_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Tue Jul 12 06:55:15 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 12 Jul 2011 04:55:15 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1310446515.57.0.426026056.issue12434@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

In my opinion, it's the error messages and docstrings that should be changed, not the documentation. This module was introduced in 2.6 and moves on to 2.7, and there's no reason to have it throw confusing errors for the sake of easier back-patching from 3.x

However, when I run this example on 2.6, I get:

   TypeError: can't write str to text stream

Which (arguably) makes sense, since the docs explicitly say that "Text I/O classes work with unicode data."

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Tue Jul 12 08:30:34 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 12 Jul 2011 06:30:34 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1310452234.74.0.704032551316.issue12531@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/issue12531>
_______________________________________

From report at bugs.python.org  Tue Jul 12 08:36:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Jul 2011 06:36:26 +0000
Subject: [issue12522] Implement `os.startfile` under Linux and Mac
In-Reply-To: <1310212746.09.0.561501840609.issue12522@psf.upfronthosting.co.za>
Message-ID: <1310452586.83.0.24846762881.issue12522@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/issue12522>
_______________________________________

From report at bugs.python.org  Tue Jul 12 09:00:02 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 12 Jul 2011 07:00:02 +0000
Subject: [issue12539] multiprocessing.Event.wait(n) doesn't time out properly
In-Reply-To: <1310425582.71.0.534887879142.issue12539@psf.upfronthosting.co.za>
Message-ID: <1310454002.74.0.187447897504.issue12539@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Are you using a 2.6.38 kernel?
There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT with a timeout to never return after a suspend-resume, see:
https://lkml.org/lkml/2011/4/13/23

It's been fixed by this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0cd9c6494ee5c19aef085152bc37f3a4e774a9e1

Could you try with a more recent kernel (it should be fixed in 2.6.38.4)?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12539>
_______________________________________

From report at bugs.python.org  Tue Jul 12 09:15:18 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Jul 2011 07:15:18 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1310454918.28.0.247789202616.issue12436@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Nice, I didn't know we have those comprehensive using docs. However, they should be linked from http://docs.python.org/dev/tutorial/interpreter.html (definitely inline and perhaps a see also).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Tue Jul 12 09:28:56 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Jul 2011 07:28:56 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310455736.37.0.858077918313.issue12535@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The ordering is as it is so that the last line in the displayed traceback corresponds to the exception that was actually caught. That is, the last line remains the same regardless of whether or not there was an earlier exception in the chain. Without that, the caught exception would be buried in the middle of a wall of text:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
    self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in replace_header
    print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in __getattr__
    self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'
^^^^^^^^^^^^^^^^CAUGHT THIS
This exception was caught while handling:
Traceback (most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in __getattr__
    return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'
^^^^^^^^^^^^^^^^NOT THIS

The consequence is that the outermost call in the call stack ends up buried in the middle of a wall of text instead. That's not optimal either, but we have to choose one or the other and I think the status quo is the better choice.

However, not closing this yet, as I think RDM may have a valid point: should we put something at the *start* of the truncated traceback to indicate that it was cut short due to another exception? For example:

Traceback (truncated due to later exception, most recent call last):
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in __getattr__
    return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
    self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in replace_header
    print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in __getattr__
    self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Tue Jul 12 10:25:47 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Jul 2011 08:25:47 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310459147.12.0.312624503013.issue4376@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is there a unit test about the actual feature: that the bytes are actually swapped in the structure?

For example, with a
class T(BigEndianStructure): _fields_ = [("a", c_int), ("b", c_int)]
cast a pointer to T into a pointer to c_int, and read the values.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Tue Jul 12 10:46:48 2011
From: report at bugs.python.org (mokrates)
Date: Tue, 12 Jul 2011 08:46:48 +0000
Subject: [issue12539] multiprocessing.Event.wait(n) doesn't time out properly
In-Reply-To: <1310454002.74.0.187447897504.issue12539@psf.upfronthosting.co.za>
Message-ID: <4E1C09F1.4040002@gmx.net>


mokrates <mmolle at gmx.net> added the comment:

> Are you using a 2.6.38 kernel?

Yes

> There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT
> with a timeout to never return after a suspend-resume, see:
> https://lkml.org/lkml/2011/4/13/23

Ah, thank you, that explains why gajim has problems too...

>  Could you try with a more recent kernel (it should be fixed in
> 2.6.38.4)?

I will, when it comes with my ubuntu... Thank you very much.

mo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12539>
_______________________________________

From report at bugs.python.org  Tue Jul 12 11:21:41 2011
From: report at bugs.python.org (Peter Caven)
Date: Tue, 12 Jul 2011 09:21:41 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>


New submission from Peter Caven <pcaven at gmail.com>:

On Windows Vista (x64) the IDLE "Restart Shell" command leaves a "pythonw.exe" process running each time that the command is used.
Observed in Python 3.2.1 release and RC2.

----------
components: IDLE
messages: 140179
nosy: Peter.Caven
priority: normal
severity: normal
status: open
title: "Restart Shell" command leaves pythonw.exe processes running
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:01:05 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jul 2011 13:01:05 +0000
Subject: [issue12485] textwrap.wrap: new argument for more pleasing output
In-Reply-To: <1309745581.79.0.51605072509.issue12485@psf.upfronthosting.co.za>
Message-ID: <1310475665.58.0.497713690644.issue12485@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/issue12485>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:17:24 2011
From: report at bugs.python.org (digi proc)
Date: Tue, 12 Jul 2011 13:17:24 +0000
Subject: [issue12219] tkinter.filedialog.askopenfilename XT dialog on Windows 7
In-Reply-To: <1306788881.55.0.171400893605.issue12219@psf.upfronthosting.co.za>
Message-ID: <1310476644.82.0.00380178931372.issue12219@psf.upfronthosting.co.za>


digi proc <grant.my at gmail.com> added the comment:

Almost certainly a tkinter bug.

A work around is below. First build a DLL from the following C++ source (and add a similar function for the 'save' dlg rather than the 'open' dlg):

#include "windows.h"
#include "Commdlg.h"
#include "tchar.h"

extern "C"{

 __declspec(dllexport)  wchar_t * _cdecl GetOpenFileNamePlus(HWND Parent,LPCWSTR InitDir,LPCWSTR FilenameIn,LPCWSTR Filter,LPCWSTR DefExt,LPCWSTR Title)
{
	OPENFILENAME OpenFile;

//	MessageBox(NULL,Title,L"",MB_OK);

	memset (&OpenFile, 0, sizeof(OPENFILENAME));

    static wchar_t Filename[MAX_PATH*2];

    _tcscpy(Filename,FilenameIn);

    OpenFile.lpstrInitialDir=InitDir;
	OpenFile.lStructSize = sizeof(OPENFILENAME);
	OpenFile.hwndOwner = Parent;
	OpenFile.lpstrFile = Filename;
	OpenFile.nMaxFile = MAX_PATH*2+10;
	OpenFile.lpstrFilter = Filter;
	OpenFile.nFilterIndex = 0;
	OpenFile.lpstrDefExt=DefExt;
	OpenFile.lpstrTitle = Title;

	OpenFile.Flags=OFN_OVERWRITEPROMPT | OFN_PATHMUSTEXIST | OFN_NOCHANGEDIR;

	long Stat=GetOpenFileName(&OpenFile);

	if(Stat)
	    return Filename;
	else
	    return NULL;
}


}

Then in python call it like this, for example:

import ctypes

commdlg=ctypes.windll.commdlg_plus
commdlg.GetOpenFileNamePlus.argtypes= [ctypes.c_void_p, ctypes.c_wchar_p, ctypes.c_wchar_p, ctypes.c_wchar_p, ctypes.c_wchar_p, ctypes.c_wchar_p]
commdlg.GetOpenFileNamePlus.restype= ctypes.c_wchar_p
s=commdlg.GetOpenFileNamePlus(0, "StartDir", "DefFilename", "Text files\0*.txt\0Image files\0*.jpg;*.gif\0\0","txt", "Select a file")

----------
nosy: +digiproc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12219>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:20:47 2011
From: report at bugs.python.org (digi proc)
Date: Tue, 12 Jul 2011 13:20:47 +0000
Subject: [issue12219] tkinter.filedialog.askopenfilename XT dialog on Windows 7
In-Reply-To: <1306788881.55.0.171400893605.issue12219@psf.upfronthosting.co.za>
Message-ID: <1310476847.36.0.0615231072996.issue12219@psf.upfronthosting.co.za>


digi proc <grant.my at gmail.com> added the comment:

By the way, that above C++ function is not re-entrant! I was lazy and just made a static return buffer. To make it re-entrant, you'd need to figure out how to allocate enough space in the DefFile string so the C function could write the selected filename to that buffer instead of making its own.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12219>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:34:38 2011
From: report at bugs.python.org (higery)
Date: Tue, 12 Jul 2011 13:34:38 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1310397438.69.0.52541021819.issue8668@psf.upfronthosting.co.za>
Message-ID: <CAHGir+HiHyrNvCnuWpBPrsyfNc6BqT855QM=e+=ccK5BYdNhPw@mail.gmail.com>


higery <shoulderhigher at gmail.com> added the comment:

>
> ** After the package has been installed in-place (using the develop
> command), how does one identify it as an in development project (or in
> development mode)? -- Case 3 and 6 touch on this topic (case 3 is a little
> vague at this time), but doesn't explain what type of action is intended. So
> if we install in-place (aka, develop), how does the python interpreter find
> the package? Are we using PYTHONPATH at this point (which would be
> contradict a requirement in  case 6)?
>

There is an .egg-link file that will be used by pkg_resources to find the
develop-installed packages, so my current implementation of develop command
in packaging module also adds a .distinfo-link file in the site-packages
which will be used to identify a project is installed in development mode or
not.

----------
Added file: http://bugs.python.org/file22628/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________
-------------- next part --------------
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

** After the package has been installed in-place (using the develop command), how does one identify it as an in development project (or in development mode)? -- Case 3 and 6 touch on this topic (case 3 is a little vague at this time), but doesn&#39;t explain what type of action is intended. So if we install in-place (aka, develop), how does the python interpreter find the package? Are we using PYTHONPATH at this point (which would be contradict a requirement in ??case 6)?<br>
</blockquote><div><br>There is an .egg-link file that will be used by pkg_resources to find the develop-installed packages, so my current implementation of develop command in packaging module also adds a .distinfo-link file in the site-packages which will be used to identify a project is installed in development mode or not.<br>
</div></div><br>

From report at bugs.python.org  Tue Jul 12 15:35:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:35:30 +0000
Subject: [issue9254] __import__ docstring should recommend
	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <1310477730.22.0.11357656134.issue9254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The docstring of __import__ was updated to mention importlib in 3d490c3a019e, for #7397.  Attached patch edits the docs.

----------
keywords: +patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file22629/__import__-mention-importlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9254>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:36:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:36:06 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310477766.92.0.0731143396492.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22628/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:37:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:37:08 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310477828.34.0.15952300359.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For now, you should not worry about pkg_resources.  Write a simple pure-packaging implementation compatible with packaging; the setuptools and distribute developers will see if they want to add forward compatibility with our system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:38:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 12 Jul 2011 13:38:21 +0000
Subject: [issue12539] multiprocessing.Event.wait(n) doesn't time out properly
In-Reply-To: <1310425582.71.0.534887879142.issue12539@psf.upfronthosting.co.za>
Message-ID: <1310477901.44.0.750871146171.issue12539@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>> Are you using a 2.6.38 kernel?

> Yes

Alright, closing as invalid then.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12539>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:39:00 2011
From: report at bugs.python.org (higery)
Date: Tue, 12 Jul 2011 13:39:00 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <CACvZ6pwiWrKx5s_wiNNHpGNP3o0hF7ZdnhAAZEZHNDYPVG+uag@mail.gmail.com>
Message-ID: <CAHGir+HyGSHMLvY36ctfsUtqGPeJnD5=KmW3Y3-_Sd8OG-trRQ@mail.gmail.com>


higery <shoulderhigher at gmail.com> added the comment:

2011/7/12 Michael Mulich <report at bugs.python.org>

>
> Michael Mulich <michael.mulich at gmail.com> added the comment:
>
> The wiki page has been edited to note what the develop command will
> write to the file system. I'll restate it here as well...
>
> The develop command writes three pieces of information to the filesystem:
>  1. It calls upon the build action(s) to build the package relative to
> the package's root directory.
>  2. It calls the [build|install]_distinfo action to write the
> .dist-info metadata inside the build directory. (see also Issue 12279)
>  3. It adds the build directory's path to a .pth file.
>

You are right, what you listed above are also the things done by the
'develop' command of my current implementation. In addition, as I replied
earlier, we can also add a .distinfo-link file  more than the .pth file.

----------
Added file: http://bugs.python.org/file22630/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________
-------------- next part --------------
<br><div class="gmail_quote">2011/7/12 Michael Mulich <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Michael Mulich &lt;<a href="mailto:michael.mulich at gmail.com">michael.mulich at gmail.com</a>&gt; added the comment:<br><br>
The wiki page has been edited to note what the develop command will<br>
write to the file system. I&#39;ll restate it here as well...<br>
<br>
The develop command writes three pieces of information to the filesystem:<br>
??1. It calls upon the build action(s) to build the package relative to<br>
the package&#39;s root directory.<br>
??2. It calls the [build|install]_distinfo action to write the<br>
.dist-info metadata inside the build directory. (see also Issue 12279)<br>
??3. It adds the build directory&#39;s path to a .pth file.<br></blockquote><div><br>You are right, what you listed above are also the things done by the &#39;develop&#39; command of my current implementation. In addition, as I replied earlier, we can also add a .distinfo-link file?? more than the .pth file.<br>
</div></div>

From report at bugs.python.org  Tue Jul 12 15:40:27 2011
From: report at bugs.python.org (Alex Garel)
Date: Tue, 12 Jul 2011 13:40:27 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1310478027.48.0.873211883577.issue7559@psf.upfronthosting.co.za>


Alex Garel <alex.garel at gmail.com> added the comment:

May I?just add that I?also ran into this and give my +1?for any fix :-)

----------
nosy: +alexgarel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:41:15 2011
From: report at bugs.python.org (higery)
Date: Tue, 12 Jul 2011 13:41:15 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310478075.69.0.978019537368.issue8668@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Removed file: http://bugs.python.org/file22630/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:43:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:43:01 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1310478181.69.0.401727547746.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> So if we include the RECORD file (point number 2) without the checksum
> and size (two columns in the RECORD csv format),
Well, three columns, the last one being empty.

> we will still be PEP376 valid (maybe?), but the file verification
> information will be missing. And we don't really want this
> information because if we edit a file, the checksum and size will be
> incorrect anyhow. This missing information is not important when
> using the develop or test commands, because we are running the
> commands on a trusted local copy.
Good thinking.

> What are the consequences of not writing the checksum or size to the
> RECORD file? And does that solve the issue?
I think checksum was intended for use by uninstallers, so we?re good.  I don?t know why the size is included.


> I don't really think the "invalid PEP 376" issue is a problem: PEP
> 376 describes the metadata for installed distributions; it has
> nothing to say about built metadata for a distribution which has not
> yet been installed.
The problem is that develop is a kind of install.

> For purposes of the develop command, if a pth file is used to
> implement develop, then ideally when develop is run a RECORD file
> would be added containing only the path to that pth file, as thats
> the only file that has actually been installed
Yeah!

> (and the only one that should be removed if the develop-installed
> package is uninstalled).
Are you saying that such a RECORD file would allow any installer compatible with PEP 376 to undo a develop install?  Clever!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:43:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:43:46 +0000
Subject: [issue3565] array documentation, method names not 3.x-compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1310478226.97.0.182845073536.issue3565@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It was Antoine in fa8b57f987c5, for #8990.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:45:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:45:58 +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: <1310478358.34.0.56158642358.issue10968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached patch removes the indirection functions; the _Verbose shenanigans are left alone.  The test suite passes; I haven?t edited the doc yet.

----------
keywords: +patch
Added file: http://bugs.python.org/file22631/threading-classes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:46:46 2011
From: report at bugs.python.org (higery)
Date: Tue, 12 Jul 2011 13:46:46 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310478406.69.0.817799117283.issue8668@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file22632/2750cd9e2111.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:48:19 2011
From: report at bugs.python.org (Alex Leon)
Date: Tue, 12 Jul 2011 13:48:19 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>


New submission from Alex Leon <aeleon at gmail.com>:

It looks like some servers using basic authentication don't include quotes around the realm (example https://api.connect2field.com) as required by rfc 2617. urllib wont handle these requests and silently fails, but a simple change to the regex in AbstractBasicAuthHandler from
 
'realm=(["\'])(.*?)\\2', re.I)
to
'realm=(["\']?)(["\']*)\\2', re.I)

would make authentication more flexible.

----------
components: Library (Lib)
messages: 140191
nosy: Alex.Leon
priority: normal
severity: normal
status: open
title: Accepting Badly formed headers in urllib HTTPBasicAuth
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12541>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:49:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:49:10 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310478550.52.0.243857064599.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22614/b1b9da3b3d20.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:57:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:57:53 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1310479073.51.0.68688248408.issue12417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The former license was also present in the reST documentation.  Attached patch removes it, and also cleans up two lines: it removes a comment that duplicates a docstring, and removes the docstring from profile that you added to pstats :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:58:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:58:02 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1310479082.43.0.108981845103.issue12417@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22633/profile-free-followup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Tue Jul 12 15:59:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 13:59:46 +0000
Subject: [issue12542] Remove duplicates of cmp_to_key used in tests
In-Reply-To: <1310479186.26.0.28744944835.issue12542@psf.upfronthosting.co.za>
Message-ID: <1310479186.26.0.28744944835.issue12542@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Two test files still use their own CmpToKey after the introduction of functools.cmp_to_key.

----------
components: Tests
files: remove-custom-cmptokey.diff
keywords: patch
messages: 140193
nosy: eric.araujo, rhettinger
priority: normal
severity: normal
stage: commit review
status: open
title: Remove duplicates of cmp_to_key used in tests
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22634/remove-custom-cmptokey.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12542>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:05:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 12 Jul 2011 14:05:04 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1310479504.94.0.309089265409.issue12541@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12541>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:09:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Jul 2011 14:09:18 +0000
Subject: [issue12542] Remove duplicates of cmp_to_key used in tests
In-Reply-To: <1310479186.26.0.28744944835.issue12542@psf.upfronthosting.co.za>
Message-ID: <1310479758.07.0.27183862766.issue12542@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12542>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:10:49 2011
From: report at bugs.python.org (Michael Mulich)
Date: Tue, 12 Jul 2011 14:10:49 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <CAHGir+HyGSHMLvY36ctfsUtqGPeJnD5=KmW3Y3-_Sd8OG-trRQ@mail.gmail.com>
Message-ID: <CACvZ6pwfunh0dM2ddxtex5PVwG2gHyk_0xcz5JqvBGwz+eBxgQ@mail.gmail.com>


Michael Mulich <michael.mulich at gmail.com> added the comment:

On Tue, Jul 12, 2011 at 9:39 AM, higery <report at bugs.python.org> wrote:
>> The develop command writes three pieces of information to the filesystem:
>> ?1. It calls upon the build action(s) to build the package relative to
>> the package's root directory.
>> ?2. It calls the [build|install]_distinfo action to write the
>> .dist-info metadata inside the build directory. (see also Issue 12279)
>> ?3. It adds the build directory's path to a .pth file.
>>
>
> You are right, what you listed above are also the things done by the
> 'develop' command of my current implementation. In addition, as I replied
> earlier, we can also add a .distinfo-link file ?more than the .pth file.

I don't like the idea of a .distinfo-link file. Would it even be
necessary if we already have a .pth entry?

We should probably just use one of these files, either .distinfo-link
or .pth. The .pth implementation has the least impact on code base and
is already implemented. If we add support for a .distinfo-link, we
would then need to modify database module to support that extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:18:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 14:18:07 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310480287.73.0.082993379714.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Oh, I just realized that one thing I insisted on was wrong.

I pushed for the modules to be built in the build dir, as well as the dist-info dir, so that the build dir can be added to sys.path to let both import and packaging.database find the files.  But this breaks one important develop feature: editions to the code should be visible immediately, without having to re-run develop or build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:18:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 14:18:48 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1310480328.95.0.511450635006.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

About writing dist-info files into the build dir or the project root dir, see msg140195

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:31:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 14:31:44 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310481104.61.0.0996867751414.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, higery?s code already has an answer for me: it writes *two* paths in the .pth file, one to the build dir (so that .dist-info is found) and one to the modules root (for modules, built in place).  Anyone sees a problem with that?  (For example huge sys.path.)

In this scheme, when Python modules are edited, changes are visible instantly, when C modules are edited, a call to build_ext is required, and when the metadata is edited, build_distinfo is required.  Does that sound good?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:48:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 14:48:17 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1310482097.63.0.0753150265851.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve reviewed the last patch.  It looks like the code only installs to the global site-packages, and there is no support to install to the user site-packages or to another arbitrary location.

On Windows, normal users seem to be able to write to the global site-packages (see #12260), but on other OSes with a proper rights model <wink> that won?t do.  Luckily, PEP 370 brings us user site-packages (currently poorly documented, see #8617 and #10745), but only for 2.6, 2.7 and 3.x.  It looks like Tarek is ready to drop 2.4 compatibility for distutils2, so the question is: what to do under 2.5?

Generally, I don?t see why develop could not install to any directory.  We want a default invocation without options to Just Work?, finding a writable directory already on sys.path and writing into it, but that doesn?t exclude letting the user do what they want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:48:46 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 12 Jul 2011 14:48:46 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1310482126.45.0.392098190409.issue12449@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

> > It also creates an exe installer, not an MSI.
> Why would you think it creates an MSI?  bdist_wininst is not bdist_msi.

My concern for MSI is that this issue is referencing a change to MSI generation. I never had any expectation for wininst to generate an MSI.

If I remember correctly from trying the other day --formats=msi fails because bdist_msi is set as a valid format.

I have begun work on fixing these problems, as I've encountered them, and will be writing up issues for them soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Tue Jul 12 16:53:17 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Tue, 12 Jul 2011 14:53:17 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1310482397.52.0.502914274638.issue12449@psf.upfronthosting.co.za>


Thomas Holmes <thomas at devminded.com> added the comment:

I mean that msi is _not_ set as a valid format. I will verify this evening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Tue Jul 12 17:21:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jul 2011 15:21:05 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1310484065.3.0.401013663632.issue11553@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>>> Exactly what variants of arguments are possible, and what are their
>>> effects?
>> Does http://docs.python.org/dev/library/functions#__import__ help?
>> Does http://docs.python.org/dev/library/importlib ?
> Well somewhat overkill -- because the matter of interest was args for
> from... and import, while the docs you mention are for more
> complicated underlying functions. (Interesting nonetheless.)

importlib.import_module should not be overkill, as it was designed specifically to be more easy and correct to use than __import__.

>>> -- the __all__ variable: Does it act generally to limit visibility
>>> of a module or package's attributes, or does pertain only to the
>>> 'from...import *' statement?
>> Both. 
> I'm pretty sure that's not correct -- pretty sure that __all__ only
> specifies what's included in from...import *, and does not prevent
> access via from...import specific_attrib.  But I may have tested
> incorrectly.

Sorry, I should have clarified.  I meant that __all__ limits what ?from x import *? can see (for somemodule.__all__), and what pydoc and other tools display (for someobject.__all__).  Direct reference ?x._lalala? or explicit import ?from x import explicit_name? don?t look at __all__.
                                                     
>>> In addsitepackages(), the library directory for Windows (the else
>>> clause) is shown as lower-case 'lib' instead of 'Lib'.

Please report that as a new bug.

>>> sys
>>> Could helpfully point to a discussion of the typical items to
>>> be found in sys.path under normal circumstances
>> Hm, this would be very platform-specific.  What use cases would that
>> help?
> It would demystify how python already knows how to find various
> things under vanilla circumstances.

I?m all for demystification, so OK.  We already have platform-specific examples in site and/or sysconfig docs, so once more wouldn?t harm.

>>> 'Installing Python Modules' document
>>> "Windows has no concept of a user?s home directory, " and so on.
>> The author probably meant that there was no $HOME environment
>> variable, ~ shortcut and all that.
> Fair enough, but in actuality there *is* a user-specific location (on
> Windows) examined by site.py, which is in %APPDATA%\Python\.

That does not map to the home concept at all.  Anyway, it does not really add value to say that one OS doesn?t have something that another OS has, let?s just say that X uses something and that Y uses soemthing else.

>> Don?t confuse the prefix and the install dir.  The directory for
>> Python modules is computed as prefix + Lib/site-packages.
> Currently, under "Alternate installation: Windows (the prefix
> scheme)", it says:
>    python setup.py install --prefix="\Temp\Python" [...]
> Does this really mean "install modules to \Temp\Python\Lib\site-packages"?

I don?t know, try it in a shell!

> (And as a side point, surely installing under the Temp directory is a
> strange location to pick for an example?)

Well, the docs gotta pick something.  A tempdir is not worse than something else to demonstrate how to use a tool.

We need to have one discussion thread for each issue, to make this huge doc bug manageable.  I will go over your first message again and open one report for each point, this week if I have time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Tue Jul 12 17:29:13 2011
From: report at bugs.python.org (Paul Hildebrandt)
Date: Tue, 12 Jul 2011 15:29:13 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1310484553.98.0.290503907928.issue12417@psf.upfronthosting.co.za>


Paul Hildebrandt <paul_hildebrandt at yahoo.com> added the comment:

Good catch, thanks Eric!  You are a wonderful human being.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Tue Jul 12 19:14:34 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Tue, 12 Jul 2011 17:14:34 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1310490874.21.0.0961365436613.issue12149@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

The attached test segfaults (and passes with the patch). It wasn't clear to me where to put the test (it is a typeobject issue triggered by io) but Antoine on IRC agreed it would make sense to add it to test_io anyway.

Python 2.7 is affected too by the bug, but it doesn't trigger with _PyIOBase_finalize because it first checks for "closed" but the lookup fails (not sure why) so it doesn't try to call "close". On Python 3.3 the lookup for "closed" returned a valid descriptor from the method cache even after the type is cleared.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file22635/test_io.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Tue Jul 12 21:00:37 2011
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 12 Jul 2011 19:00:37 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1310478181.69.0.401727547746.issue12279@psf.upfronthosting.co.za>
Message-ID: <4E1C9B11.30701@dirtcircle.com>


Carl Meyer <carl at dirtcircle.com> added the comment:

>> I don't really think the "invalid PEP 376" issue is a problem: PEP
>> 376 describes the metadata for installed distributions; it has
>> nothing to say about built metadata for a distribution which has not
>> yet been installed.
> The problem is that develop is a kind of install.

Right, I was simply referring to "build_distinfo" leaving it
empty/missing; I'd want "develop" to add a (very short) RECORD file as
specified below.

>> For purposes of the develop command, if a pth file is used to
>> implement develop, then ideally when develop is run a RECORD file
>> would be added containing only the path to that pth file, as thats
>> the only file that has actually been installed
> Yeah!
> 
>> (and the only one that should be removed if the develop-installed
>> package is uninstalled).
> Are you saying that such a RECORD file would allow any installer compatible with PEP 376 to undo a develop install?  Clever!

Yeah, that's the idea. I don't see any actual use case for having all of
the Python modules etc included in the RECORD file for a
develop-install, because they haven't been installed anywhere: what we
really want to know is "what has been placed in the installation
location that we need to keep track of."?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Tue Jul 12 21:04:59 2011
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 12 Jul 2011 19:04:59 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1310481104.61.0.0996867751414.issue8668@psf.upfronthosting.co.za>
Message-ID: <4E1C9C18.4090809@dirtcircle.com>


Carl Meyer <carl at dirtcircle.com> added the comment:

> Ah, higery?s code already has an answer for me: it writes *two* paths in the .pth file, one to the build dir (so that .dist-info is found) and one to the modules root (for modules, built in place).  Anyone sees a problem with that?  (For example huge sys.path.)
> 
> In this scheme, when Python modules are edited, changes are visible instantly, when C modules are edited, a call to build_ext is required, and when the metadata is edited, build_distinfo is required.  Does that sound good?

That sounds reasonable to me. I'm not worried about that making sys.path
too long: whatever we do we aren't going to challenge buildout in that
department ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 21:16:11 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 12 Jul 2011 19:16:11 +0000
Subject: [issue12543] `issubclass(collections.deque,
	collections.Sequence) == False`
In-Reply-To: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>
Message-ID: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Is there a good reason that `issubclass(collections.deque, collections.Sequence) == False`? What's not-sequence-y about `deque`?

----------
messages: 140206
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `issubclass(collections.deque, collections.Sequence) == False`

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12543>
_______________________________________

From report at bugs.python.org  Tue Jul 12 21:20:44 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Jul 2011 19:20:44 +0000
Subject: [issue9254] __import__ docstring should recommend
	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <1310498444.8.0.733963168689.issue9254@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Patch looks good to me.

----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9254>
_______________________________________

From report at bugs.python.org  Tue Jul 12 21:30:35 2011
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 12 Jul 2011 19:30:35 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1310482097.63.0.0753150265851.issue8668@psf.upfronthosting.co.za>
Message-ID: <4E1CA216.5090005@dirtcircle.com>


Carl Meyer <carl at dirtcircle.com> added the comment:

> I?ve reviewed the last patch.  It looks like the code only installs
> to the global site-packages, and there is no support to install to
> the user site-packages or to another arbitrary location.
> 
> On Windows, normal users seem to be able to write to the global
> site-packages (see #12260), but on other OSes with a proper rights
> model <wink> that won?t do.  Luckily, PEP 370 brings us user
> site-packages (currently poorly documented, see #8617 and #10745),
> but only for 2.6, 2.7 and 3.x.  It looks like Tarek is ready to drop
> 2.4 compatibility for distutils2, so the question is: what to do
> under 2.5?
> 
> Generally, I don?t see why develop could not install to any
> directory.  We want a default invocation without options to Just
> Work?, finding a writable directory already on sys.path and writing
> into it, but that doesn?t exclude letting the user do what they
> want.

I don't see why the installation-location-finding for develop should be
any different than for a normal "pysetup install". Does "pysetup
install" install to global site-packages by default, or try to find
somewhere it can install without additional privileges? Whatever it does
by default, develop should do the same. If "develop" can install to
arbitrary locations, then "install" should be able to as well (though I
don't really see the value in "arbitrary locations", since you then have
to set up PYTHONPATH manually anyway). There is no reason for them to
have different features in this area, it just adds confusion.

Certainly "develop" should support PEP 370, ideally with the same
command-line flag as a regular install.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Jul 12 21:49:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jul 2011 19:49:01 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1310500141.42.0.784070568676.issue12149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you very much!

----------
stage: needs patch -> patch review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Tue Jul 12 21:51:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jul 2011 19:51:44 +0000
Subject: [issue3565] array documentation, method names not 3.x-compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1310500304.01.0.382388351265.issue3565@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is there still any idea/intention of renaming .from/.tounicode to
> .from/.tostring? That would have to be done at least one version with
> the 'string' names absent, and would have little gain as 'unicode' is
> clear.

Indeed, not only it would bring little benefit, but may also confuse users porting from 2.x (since the from/tostring methods would then have a totally different meaning).

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> array constructor and array.fromstring should accept bytearray.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Tue Jul 12 22:01:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jul 2011 20:01:48 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <E1Qgj9O-0003q1-L2@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cd40ea4087b0 by Antoine Pitrou in branch '3.2':
Issue #12149: Update the method cache after a type's dictionnary gets
http://hg.python.org/cpython/rev/cd40ea4087b0

New changeset 5992cbbedf59 by Antoine Pitrou in branch 'default':
Issue #12149: Update the method cache after a type's dictionnary gets
http://hg.python.org/cpython/rev/5992cbbedf59

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Tue Jul 12 22:05:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Jul 2011 20:05:51 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <E1QgjDK-0004JF-Gu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9618303852da by Antoine Pitrou in branch '2.7':
Issue #12149: Update the method cache after a type's dictionnary gets
http://hg.python.org/cpython/rev/9618303852da

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Tue Jul 12 22:06:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Jul 2011 20:06:35 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1310501195.97.0.490804079314.issue12149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now. Thanks again Davide for the patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Tue Jul 12 22:47:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jul 2011 20:47:50 +0000
Subject: [issue12543] `issubclass(collections.deque,
	collections.Sequence) == False`
In-Reply-To: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>
Message-ID: <1310503670.41.0.983192103112.issue12543@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Maybe they don't support all Sequence operations?  They don't support slicing, certainly, but I can't tell from the collections ABC docs if Sequence is required to support slicing.

----------
nosy: +r.david.murray, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12543>
_______________________________________

From report at bugs.python.org  Tue Jul 12 22:57:37 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 12 Jul 2011 20:57:37 +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: <1310504257.51.0.297152901145.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Well, my brain did not deadlock, but after spinning on the problem for a while longer, it now thinks Toma? ?olc and Steffen are right.

We should try to fix the multiprocessing module so it does not deadlock single-thread programs and deprecate fork in multi-threaded programs.

Here is the longer version, which is a summary of what people said here in various forms, observations from diving into the code and Googling around:


1) The rabbit hole

a) In a multi-threaded program, fork() may be called while another thread is in a critical section. That thread will not exist in the child and the critical section will remain locked. Any attempt to enter that critical section will deadlock the child.

b) POSIX included the pthread_atfork() API in an attempt to deal with the problem:
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html

c) But it turns out atfork handlers are limited to calling async-signal-safe functions since fork may be called from a signal handler:
http://download.oracle.com/docs/cd/E19963-01/html/821-1601/gen-61908.html#gen-95948

This means atfork handlers may not actually acquire or release locks. See opinion by David Butenhof who was involved in the standardization effort of POSIX threads:
http://groups.google.com/group/comp.programming.threads/msg/3a43122820983fde

d) One consequence is that we can not assume third party libraries are safe to fork in multi-threaded program. It is likely their developers consider this scenario broken.

e) It seems the general consensus across the WWW concerning this problem is that it has no solution and that a fork should be followed by exec as soon as possible.

Some references:
http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html
http://austingroupbugs.net/view.php?id=62
http://sourceware.org/bugzilla/show_bug.cgi?id=4737
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them


2) Python?s killer rabbit

The standard library multiprocessing module does two things that force us into the rabbit hole; it creates worker threads and forks without exec.

Therefore, any program that uses the multiprocessing module is a multi-threading forking program.

One immediate problem is that a multiprocessing.Pool may fork from its worker thread in Pool._handle_workers(). This puts the forked child at risk of deadlock with any code that was run by the parent?s main thread (the entire program logic).

More problems may be found with a code review.

Other modules to look at are concurrent.futures.process (creates a worker thread and uses multiprocessing) and socketserver (ForkingMixIn forks without exec).


3) God bless the GIL

a) Python signal handlers run synchronously in the interpreter loop of the main thread, so os.fork() will never be called from a POSIX signal handler.

This means Python atfork prepare and parent handlers may run any code. The code run at the child is still restricted though and may deadlock into any acquired locks left behind by dead threads in the standard library or lower level third party libraries.

b) Turns out the GIL also helps by synchronizing threads.

Any lock held for the duration of a function call while the GIL is held will be released by the time os.fork() is called. But if a thread in the program calls a function that yields the GIL we are in la la land again and need to watch out step.


4) Landing gently at the bottom

a) I think we should try to review and sanitize the worker threads of the multiprocessing module and other implicit worker threads in the standard library.

Once we do (and since os.fork() is never run from a POSIX signal handler) the multiprocessing library should be safe to use in programs that do not start other threads.

b) Then we should declare the user scenario of mixing the threading and multiprocessing modules as broken by design.

c) Finally, optionally provide atfork API

The atfork API can be used to refactor existing fork handlers in the standard library, provide handlers for modules such as the logging module that will reduce the risk of deadlock in existing programs, and can be used by developers who insist on mixing threading and forking in their programs.


5) Sanitizing worker threads in the multiprocessing module

TODO :) 

(will try to post some ideas soon)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Wed Jul 13 01:08:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Jul 2011 23:08:35 +0000
Subject: [issue12543] `issubclass(collections.deque,
	collections.Sequence) == False`
In-Reply-To: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>
Message-ID: <1310512115.21.0.406366837167.issue12543@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

index() isn't supported.

----------
assignee:  -> rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12543>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:05:54 2011
From: report at bugs.python.org (Martin)
Date: Wed, 13 Jul 2011 00:05:54 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>


New submission from Martin <gzlist at googlemail.com>:

The fix for issue 10326 landing on Python 2.7 trunk has interfered with a hack I wrote in Bazaar to break the reference cycles the private `unittest.TestCase._type_equality_funcs` member creates.

As the change to make pickling work is nearly enough to avoid the test and the dict referencing each other, it would be good to remove that breakage and the need for the hack in the first place.

Downstream bug:

<https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/809048>

----------
components: Library (Lib)
messages: 140217
nosy: MarkRoddy, gz, michael.foord
priority: normal
severity: normal
status: open
title: Avoid using a pseudo-dict for _type_equality_funcs in unittest
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:08:58 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 13 Jul 2011 00:08:58 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310515738.29.0.305253385603.issue12544@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It isn't clear to me exactly what fix you are suggesting for Python 2.7?

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:11:28 2011
From: report at bugs.python.org (Martin)
Date: Wed, 13 Jul 2011 00:11:28 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310515888.61.0.748614720719.issue12544@psf.upfronthosting.co.za>


Changes by Martin <gzlist at googlemail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22636/avoid_TestCase_refcycle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:12:25 2011
From: report at bugs.python.org (Martin)
Date: Wed, 13 Jul 2011 00:12:25 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310515945.62.0.518227411036.issue12544@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

Michael: See attached patch, that should merge up to Python 3 without too much pain as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:15:51 2011
From: report at bugs.python.org (Martin)
Date: Wed, 13 Jul 2011 00:15:51 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310516151.19.0.202941942957.issue12544@psf.upfronthosting.co.za>


Changes by Martin <gzlist at googlemail.com>:


Removed file: http://bugs.python.org/file22636/avoid_TestCase_refcycle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:19:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jul 2011 00:19:07 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <E1QgnAQ-0007Vw-5p@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 02a591131360 by Benjamin Peterson in branch '2.7':
this can be done without a custom dict (also fixes #12544)
http://hg.python.org/cpython/rev/02a591131360

New changeset 842f5ed06255 by Benjamin Peterson in branch '3.2':
this can be done without a custom dict (also fixes #12544)
http://hg.python.org/cpython/rev/842f5ed06255

New changeset 47a36d2d2b44 by Benjamin Peterson in branch 'default':
merge 3.2 (#12544)
http://hg.python.org/cpython/rev/47a36d2d2b44

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:19:54 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Jul 2011 00:19:54 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310516394.92.0.509231448365.issue12544@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 02:20:27 2011
From: report at bugs.python.org (Martin)
Date: Wed, 13 Jul 2011 00:20:27 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310516427.92.0.33634282587.issue12544@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

...typo in the first patch, this one should be okay. But... already landed without the testcase?

----------
Added file: http://bugs.python.org/file22637/avoid_TestCase_refcycle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 05:29:19 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Wed, 13 Jul 2011 03:29:19 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>


New submission from Kuberan Naganathan <kubiyak at gmail.com>:

The lseek function can legitimately return a code less then zero ( except for -1 ) when seeking beyond an offset of 2^63.  This behavior should be supported in order to permit the python interpreter to seek in files with valid data at locations greater than or equal to 2^63.  This can happen in a sparse file or in the /proc file system address space file.  

The fix is simple.  In the posix_lseek function check for result != -1 instead of checking for result < 0 in return code checks of the value returned by lseek.

----------
components: IO
messages: 140222
nosy: Kuberan.Naganathan
priority: normal
severity: normal
status: open
title: Incorrect handling of return codes in the posix_lseek function in posixmodule.c
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 05:50:44 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Wed, 13 Jul 2011 03:50:44 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310529044.05.0.414780030294.issue12545@psf.upfronthosting.co.za>


Kuberan Naganathan <kubiyak at gmail.com> added the comment:

In addition I would like the posix_lseek function to accept a value larger than 2^63 as a seek offset.  Currently I seem to need to seek multiple times within a file to achieve an offset larger than 2^63 ( assuming the return type check on the return value of lseek is fixed. )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 05:57:48 2011
From: report at bugs.python.org (Matt Giuca)
Date: Wed, 13 Jul 2011 03:57:48 +0000
Subject: [issue3565] array documentation, method names not 3.x-compliant
In-Reply-To: <1218878053.61.0.879399084038.issue3565@psf.upfronthosting.co.za>
Message-ID: <1310529468.41.0.222174114219.issue3565@psf.upfronthosting.co.za>


Matt Giuca <matt.giuca at gmail.com> added the comment:

There are still some inconsistencies in the documentation (in particular, incorrectly using the word "string" to refer to a bytes object, which made sense in Python 2 but not 3), which I fixed in my doc-only.patch file that's coming up to its third birthday.

Most of it has been fixed with the previous change which added 'tobytes' and 'frombytes' and made tostring and fromstring aliases. But there are some places which don't make sense:

array: "If given a list or string" needs to be "If given a list, bytes or string" (since a bytes is not a string).
frombytes: "Appends items from the string" needs to be "Appends items from the bytes object", since this does not work if you give it a string.

Less importantly, I also recommended renaming "unicode string" to just "string", since in Python 3 there is no such thing as a non-unicode string. For instance, there is an example that uses a variable named "unicodestring" that could be renamed to just "string".

> Indeed, not only it would bring little benefit, but may also confuse
> users porting from 2.x (since the from/tostring methods would then
> have a totally different meaning).
Well, by that logic, you shouldn't have renamed "unicode" to "str" since that would also confuse users porting from 2.x. It generally seems like a good idea in Python 3 to rename all mentions of "string" to "bytes" and all mentions of "unicode" to "string", so as to be consistent with the new names of the types (it is better to be internally consistent than consistent with the previous version).

Though I do agree that it would be chaos to rename array.from/tounicode to from/tostring now, given that array.from/tostring already has a different meaning in Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3565>
_______________________________________

From report at bugs.python.org  Wed Jul 13 08:58:06 2011
From: report at bugs.python.org (Gavin Andresen)
Date: Wed, 13 Jul 2011 06:58:06 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>


New submission from Gavin Andresen <gavinandresen at gmail.com>:

This gives me "foo   " instead of expected "foo\x00\x00\x00" :

"{0:\x00<6}".format('foo')

----------
components: Library (Lib)
messages: 140225
nosy: Gavin.Andresen
priority: normal
severity: normal
status: open
title: str.format cannot fill with \x00 char
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 09:08:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 07:08:05 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310540885.92.0.803302772307.issue12546@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eric.smith, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 09:47:32 2011
From: report at bugs.python.org (Sebastian)
Date: Wed, 13 Jul 2011 07:47:32 +0000
Subject: [issue4028] Problem compiling the multiprocessing module on sunos5
In-Reply-To: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>
Message-ID: <1310543252.28.0.0954060109267.issue4028@psf.upfronthosting.co.za>


Sebastian <sebastian.malyska at gmail.com> added the comment:

Yes, it is. I encountered it at Solaris9 with python 2.7.1.

----------
nosy: +SebaM6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4028>
_______________________________________

From report at bugs.python.org  Wed Jul 13 09:51:48 2011
From: report at bugs.python.org (Santiago Romero)
Date: Wed, 13 Jul 2011 07:51:48 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310543508.39.0.0494174695906.issue1170@psf.upfronthosting.co.za>


Santiago Romero <sromero at gmail.com> added the comment:

I think I'm suffering the same problem in some small programs that use shlex:


>>> import shlex

>>> text = "python and shlex"
>>> shlex.split(text)
['python', 'and', 'shlex']

>>> text = u"python and shlex"
>>> shlex.split(text)
['p\x00\x00\x00y\x00\x00\x00t\x00\x00\x00h\x00\x00\x00o\x00\x00\x00n\x00\x00\x00', '\x00\x00\x00a\x00\x00\x00n\x00\x00\x00d\x00\x00\x00', '\x00\x00\x00s\x00\x00\x00h\x00\x00\x00l\x00\x00\x00e\x00\x00\x00x\x00\x00\x00']


 I'm currently using the following "basic" workaround (while assuming that my strings have only ascii chars):

>>> [ x.replace("\0", "") for x in shlex.split(text) ]
['python', 'and', 'shlex']

 It would be very nice if shlex could work with unicode strings ...

 Thanks.

----------
nosy: +Santiago.Romero

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Wed Jul 13 09:56:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 07:56:10 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310543770.65.0.367923854142.issue1170@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/issue1170>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:13:31 2011
From: report at bugs.python.org (July Tikhonov)
Date: Wed, 13 Jul 2011 08:13:31 +0000
Subject: [issue12547] whatsnew/3.3: error in example about nntplib
In-Reply-To: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>
Message-ID: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

>>> from nntplib import NNTP
>>> with nntplib.NNTP('news.gmane.org') as n:

will not work. It should be

>>> import nntplib
>>> with nntplib.NNTP('news.gmane.org') as n:

or

>>> from nntplib import NNTP
>>> with NNTP('news.gmane.org') as n:

----------
assignee: docs at python
components: Documentation
files: whatsnew.3.3.nntplib.example.diff
keywords: patch
messages: 140228
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: whatsnew/3.3: error in example about nntplib
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22638/whatsnew.3.3.nntplib.example.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12547>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:18:41 2011
From: report at bugs.python.org (Bharadwaj)
Date: Wed, 13 Jul 2011 08:18:41 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310545121.59.0.106625221844.issue12524@psf.upfronthosting.co.za>


Bharadwaj <barbi.bruce at gmail.com> added the comment:

Newbie to python dev. 
This looks like a good issue to get started with and I am interested in creating a patch.
What should the new URL be? python.org:80?

----------
nosy: +barbi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:22:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 08:22:28 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310545348.68.0.589870880239.issue12524@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

You'll need a page that accepts POST requests, possibly returning some meaningful value, and without side effects (e.g. adding messages is usually done via POST, but we don't want a new message for every user that tries the example).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:24:56 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 13 Jul 2011 08:24:56 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310545496.69.0.955473330959.issue12546@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

\x00 is used as a flag internally meaning "use the default fill character". That's clearly a bug. I'll look at fixing it.

I think there are other places in the built in __format__ functions where special values are used instead of flags. I'll review those as well.

Thanks for the report!

----------
assignee:  -> eric.smith
components: +Interpreter Core -Library (Lib)
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:35:20 2011
From: report at bugs.python.org (Bharadwaj)
Date: Wed, 13 Jul 2011 08:35:20 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310546120.71.0.0110976239073.issue12524@psf.upfronthosting.co.za>


Bharadwaj <barbi.bruce at gmail.com> added the comment:

Is there someway to create a test page in python.org instead of an external domain? This can ensure many people have access to it and will not become defunct.
Please suggest next steps to proceed with this ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:36:14 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 08:36:14 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310546174.72.0.578341001867.issue12546@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

This patch removes the special meaning for \x00 and defines the default padding character (' ') in parse_internal_render_format_spec. Test included. Maybe the default padding character should be defined elsewhere?

----------
keywords: +patch
nosy: +davide.rizzo
Added file: http://bugs.python.org/file22639/format00.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:40:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 08:40:52 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310546452.14.0.386925318636.issue12524@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW the 'show issue' button on the left sidebar of http://bugs.python.org/ uses POST, so maybe you could send an issue number as request there to get back the issue page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:42:55 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 08:42:55 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310546575.8.0.0661515298721.issue12546@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Oops, sorry. Above patch was overly buggy. Please just ignore it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:44:17 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 08:44:17 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310546657.88.0.508330214219.issue12546@psf.upfronthosting.co.za>


Changes by Davide Rizzo <sorcio at gmail.com>:


Removed file: http://bugs.python.org/file22639/format00.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:45:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jul 2011 08:45:00 +0000
Subject: [issue12547] whatsnew/3.3: error in example about nntplib
In-Reply-To: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>
Message-ID: <E1Qgv3z-0004Ax-4m@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e0cd35660ae9 by Ezio Melotti in branch 'default':
#12547: Fix import and output in nntplib example. Initial patch by July Tikhonov.
http://hg.python.org/cpython/rev/e0cd35660ae9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12547>
_______________________________________

From report at bugs.python.org  Wed Jul 13 10:48:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 08:48:34 +0000
Subject: [issue12547] whatsnew/3.3: error in example about nntplib
In-Reply-To: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>
Message-ID: <1310546914.65.0.406007535823.issue12547@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report and the patch!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12547>
_______________________________________

From report at bugs.python.org  Wed Jul 13 11:07:45 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 09:07:45 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310548065.01.0.415726751156.issue12546@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Here's the patch. Same rationale as above (removed the special meaning of '\x00', default specified in parse_internal_render_format_spec). Sorry about the mess again!

----------
Added file: http://bugs.python.org/file22640/format00.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 11:35:28 2011
From: report at bugs.python.org (yura levchenko)
Date: Wed, 13 Jul 2011 09:35:28 +0000
Subject: [issue12548] Add suport native Functor
In-Reply-To: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>
Message-ID: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>


New submission from yura levchenko <levchenko.yuriy.vladimirovich at gmail.com>:

sample:

def foo(a,b):
 print a,b

foo(1,2)
fa = foo%(1)
fa(2)
fab = foo%(1,2)
fab()

result

12
12
12

----------
components: None
messages: 140239
nosy: yura.levchenko
priority: normal
severity: normal
status: open
title: Add suport native Functor
type: feature request
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12548>
_______________________________________

From report at bugs.python.org  Wed Jul 13 11:43:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 09:43:09 +0000
Subject: [issue12548] Add suport native Functor
In-Reply-To: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>
Message-ID: <1310550189.93.0.683973252135.issue12548@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It's not entirely clear to me what you are proposing, but it looks like functools.partial[0].  Whatever it is, adding new syntax especially for it sounds highly unlikely. You might want to propose and discuss it on python-ideas though.

[0]: http://docs.python.org/library/functools.html#functools.partial

----------
nosy: +ezio.melotti, rhettinger
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12548>
_______________________________________

From report at bugs.python.org  Wed Jul 13 11:49:23 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 09:49:23 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

test test_platform failed -- Traceback (most recent call last):
  File "/Users/davide/cpython/Lib/test/test_platform.py", line 194, in test_mac_ver
    self.assertEqual(res[2], 'i386')
AssertionError: 'x86_64' != 'i386'
- x86_64
+ i386


uname reports machine as "x86_64", but the test expects "i386".

Related: the Gestalt call makes no difference between i386 and x86_64 and may only return "i386" as the machine.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 140241
nosy: davide.rizzo, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_platform test_mac_ver fails on Darwin x86_64
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 12:01:54 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 13 Jul 2011 10:01:54 +0000
Subject: [issue12546] str.format cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1310551314.28.0.44600311116.issue12546@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Patch looks good at first glance. I'll review it some more today and commit it. Thanks!

----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Wed Jul 13 12:14:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 10:14:12 +0000
Subject: [issue12550] regrtest: register SIGALRM signal using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Sometimes, some tests are stopped because of SIGALRM. A recent example:
-----------------------
[157/357] test_socketserver
Alarm clock
*** Error code 142
-----------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1647/steps/test/logs/stdio

faulthandler is able to dump the Python backtrace in such case, we just have to register the SIGALRM signal handler. regrtest should be patched: just add faulthandler.register(signal.SIGALRM).

It would be nice if faulthandler calls the previous signal handler. By default, it replaces the existing signal handler and so it changes the behaviour.

A test should also be added to faulthandler for SIGALRM, this signal is special because of its default signal handler (it exits the process).

----------
components: Tests
messages: 140243
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: register SIGALRM signal using faulthandler
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12550>
_______________________________________

From report at bugs.python.org  Wed Jul 13 12:17:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 10:17:06 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1310552226.36.0.162479874683.issue12149@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oooh, an interesting and complex bug with an one-liner fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Wed Jul 13 13:14:34 2011
From: report at bugs.python.org (Sebastian M)
Date: Wed, 13 Jul 2011 11:14:34 +0000
Subject: [issue4028] Problem compiling the multiprocessing module on sunos5
In-Reply-To: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>
Message-ID: <1310555674.89.0.493267973935.issue4028@psf.upfronthosting.co.za>


Sebastian M <sebastian.malyska at gmail.com> added the comment:

One more thing, as I tried to rebuild whole python I've encountered on following problem:

building '_multiprocessing' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -IInclude -I./Include -I/usr/local/include -I/home/malyska/bld/python_sol10/Python-2.7.1/Include -I/home/malyska/bld/python_sol10/Python-2.7.1 -c /home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.c -o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -IInclude -I./Include -I/usr/local/include -I/home/malyska/bld/python_sol10/Python-2.7.1/Include -I/home/malyska/bld/python_sol10/Python-2.7.1 -c /home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.c -o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I. -IInclude -I./Include -I/usr/local/include -I/home/malyska/bld/python_sol10/Python-2.7.1/Include -I/home/malyska/bld/python_sol10/Python-2.7.1 -c /home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.c -o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o
gcc -shared build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/multiprocessing.o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/socket_connection.o build/temp.solaris-2.9-sun4u-2.7/home/malyska/bld/python_sol10/Python-2.7.1/Modules/_multiprocessing/semaphore.o -L/home/malyska/bld/python_sol10/install/lib -L/usr/local/lib -o build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so
*** WARNING: renaming "_multiprocessing" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.9-sun4u-2.7/_multiprocessing.so: symbol sem_timedwait: referenced symbol not found

so I had to commented out HAVE_SEM_TIMEDWAIT from setup.py, see:
             elif platform.startswith('sunos5'):
                  macros = dict(
                      HAVE_SEM_OPEN=1,
                      HAVE_FD_TRANSFER=1
                      )
                      #HAVE_SEM_TIMEDWAIT=0,
                  libraries = ['rt']
thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4028>
_______________________________________

From report at bugs.python.org  Wed Jul 13 13:15:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 11:15:42 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310555742.98.0.14701689927.issue1170@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This isn't going to get fixed in 2.x (shlex doesn't support unicode in 2.x, and doing so would be a new feature).  In 3.x all strings are unicode, so the problem you are seeing doesn't exist.  This issue is about the broader problem of what counts as a word character when more than ASCII is involved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Wed Jul 13 13:33:25 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Wed, 13 Jul 2011 11:33:25 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>


New submission from Jacek Konieczny <jajcus at jajcus.net>:

Recently IETF encourages using of the SCRAM-SHA-1-PLUS SASL authentication mechanism (5802) in new protocols. That is a requirement e.g. of the current XMPP specification (RFC6120). Any compliant implementation needs to support the 'SCRAM-SHA-1-PLUS' mechanism, and that requires obtaining the 'tls-unique' channel-binding data from a TLS connection used. Python doesn't provide this information and it seems the only detail stopping anyone from fully implementing XMPP or SCRAM-SHA-1-PLUS alone in Python.

The 'tls-unique' channel binding is defined as:

> Description: The first TLS Finished message sent (note: the Finished
> struct, not the TLS record layer message containing it) in the most
> recent TLS handshake of the TLS connection being bound to

?and is (they say), available via OpenSSL API. This should be exposed by the python SSLSocket object too.

The other channel-binding data type, 'tls-server-end-point' can be computed using current Python API, but it is not enough for most uses ('tls-unique' is the required channel binding data in most cases) and still not trivial (one needs to ASN.1-decode the certificate to get the hash function name to compute proper digest).

----------
components: Library (Lib)
messages: 140247
nosy: Jajcus
priority: normal
severity: normal
status: open
title: Provide data for TLS channel binding
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Wed Jul 13 13:52:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 11:52:09 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310557929.91.0.761644729946.issue12551@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Interestingly (from rfc5929):

      This definition of 'tls-unique' means that a channel's bindings
      data may change over time, which in turn creates a synchronization
      problem should the channel's bindings data change between the time
      that the client initiates authentication with channel binding and
      the time that the server begins to process the client's first
      authentication message.  If that happens, the authentication
      attempt will fail spuriously.

> and is (they say), available via OpenSSL API

Do you happen to know which API? I see no reference to tls-unique or channel binding, in either the OpenSSL website or the latest OpenSSL snapshot.

According to some mailing-list message, we could use SSL_get_finished() and SSL_get_peer_finished(), but that still leaves us to figure out what to do with the info returned by these functions. It would be nice if there was some ready-to-use code (I'm not a crypto expert).

----------
nosy: +pitrou
stage:  -> needs patch
versions:  -Python 2.7, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Wed Jul 13 14:05:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 12:05:56 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310558756.19.0.383235824485.issue12545@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/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 14:07:43 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Wed, 13 Jul 2011 12:07:43 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310558863.26.0.0185079206163.issue12551@psf.upfronthosting.co.za>


Jacek Konieczny <jajcus at jajcus.net> added the comment:

> Do you happen to know which API? 

Not yet.

> I see no reference to tls-unique or channel binding, in either the OpenSSL website or the latest OpenSSL snapshot.

Yes, I know it is not directly documented.

> It would be nice if there was some ready-to-use code (I'm not a crypto expert).

_Maybe_ I will try to hack the python SSL code to make this work within my project. I will attach a patch here if it happens and gives any reusable results. As for now I cannot help any more, I am just reporting what is missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Wed Jul 13 14:09:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 12:09:55 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310558995.81.0.521451419494.issue12545@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In addition I would like the posix_lseek function to accept a value
> larger than 2^63 as a seek offset

How would it work? The C lseek() takes a signed (64-bit) offset as argument, so we would have to call it multiple times anyway.

----------
nosy: +neologix, pitrou
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 14:15:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 12:15:48 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1310559348.31.0.863705033286.issue12531@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/issue12531>
_______________________________________

From report at bugs.python.org  Wed Jul 13 14:21:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 12:21:05 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1310559665.39.0.611520205382.issue12527@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12527>
_______________________________________

From report at bugs.python.org  Wed Jul 13 15:08:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 13:08:28 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310562508.69.0.221417683641.issue12545@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"... A negative file offset may be valid for some devices in some implementations.

The POSIX.1-1990 standard did not specifically prohibit lseek() from returning a negative offset. Therefore, an application was required to clear errno prior to the call and check errno upon return to determine whether a return value of ( off_t)-1 is a negative offset or an indication of an error condition. The standard developers did not wish to require this action on the part of a conforming application, and chose to require that errno be set to [EINVAL] when the resulting file offset would be negative for a regular file, block special file, or directory."

Extract of:
http://pubs.opengroup.org/onlinepubs/009695399/functions/lseek.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:14:50 2011
From: report at bugs.python.org (Sye van der Veen)
Date: Wed, 13 Jul 2011 14:14:50 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1310566490.41.0.0756822056773.issue10224@psf.upfronthosting.co.za>


Sye van der Veen <syeberman at gmail.com> added the comment:

When I built the documentation on Win7, it failed with a SyntaxError, and it took some digging to find the reason why.  I was hoping that issuing this warning would save others the trouble.

I agree: on Windows, PYTHON is rarely set.  However, look in make.bat: you'll see that when PYTHON is not already set, it's set to ..\pcbuild\python, which is Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:21:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 13 Jul 2011 14:21:17 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310566877.23.0.272932662273.issue12545@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> In the posix_lseek function check for result != -1 instead of checking
> for result < 0 in return code checks of the value returned by lseek.

+1
This can be useful when parsing /dev/mem on x86_64, for example.

> In addition I would like the posix_lseek function to accept a value
> larger than 2^63 as a seek offset

Like Antoine, I'm a little bit puzzled here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:24:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 14:24:06 +0000
Subject: [issue12536] lib2to3 BaseFix class creates un-needed loggers leading
	to refleaks
In-Reply-To: <1310407101.06.0.821103833142.issue12536@psf.upfronthosting.co.za>
Message-ID: <1310567046.33.0.754297859192.issue12536@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If the logger attribute is part of the official API and Benjamin doesn?t think it wise to just remove it, I think we should either start deprecating it (using a property), or set it to a shared logger object instead of creating one per file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12536>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:27:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 14:27:04 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310567224.27.0.749430834661.issue12544@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What?s the typo?

About the test case: Benjamin probably judged that testing this internal detail was not worth it, as long as the code was readable and working.

----------
nosy: +benjamin.peterson, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:30:00 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Jul 2011 14:30:00 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310567400.74.0.188468276081.issue12544@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually, what happened was I saw the bug report, didn't see your patch, and started working on my own patch. I see we came to roughly the same conclusion, though. :) About the test, I'm not sure testcases having no cyclic references is part of the guarantee of the API. Perhaps Michael can chime in on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:34:07 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Jul 2011 14:34:07 +0000
Subject: [issue12536] lib2to3 BaseFix class creates un-needed loggers leading
	to refleaks
In-Reply-To: <1310407101.06.0.821103833142.issue12536@psf.upfronthosting.co.za>
Message-ID: <1310567647.3.0.98990122785.issue12536@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I say kill the loggers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12536>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:36:01 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Wed, 13 Jul 2011 14:36:01 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310567761.4.0.0589548663094.issue12551@psf.upfronthosting.co.za>


Jacek Konieczny <jajcus at jajcus.net> added the comment:

I skim-read the TLS specification, looked at the OpenSSL API and it seems it should be easy to implement. I am getting to work right now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:37:35 2011
From: report at bugs.python.org (Blame-me Jaillie)
Date: Wed, 13 Jul 2011 14:37:35 +0000
Subject: [issue12552] email.MIMEText overide BASE64 on TEXT/HTML
In-Reply-To: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>
Message-ID: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>


New submission from Blame-me Jaillie <darkshado.1972 at gmail.com>:

Apologies if this is in the wrong place.

Simple enough issue. This line of code from email.mime:

MIMEText(textonly, 'plain', _charset='UTF-8')
Where 'textonly' is just a plain text email message to be displayed on a multipart message in a client that does not support HTML email.

This always results in: Content-Transfer-Encoding: BASE64
rather than allowing selection of the encoder (7 or 8 bit MIME/quoted printable). The option to set this with _encoders was removed.

This presents a couple of issues. First of all, BASE64 is not optimal for text - it adds (granted small) amounts of overhead and CPU usage. Second, commercial and O/S anti-spam scanners have rules that penalise messages solely BASE64 encoded.

As this is part of the mime email package, a simple flag to set the Content-Transfer-Encoding by hand would be help anyone trying to produce sensible email applications with Python.

Whilst my version of Python is old - I believe this issue remains in later versions.

----------
components: None
messages: 140259
nosy: Blame-me.Jaillie
priority: normal
severity: normal
status: open
title: email.MIMEText overide BASE64 on TEXT/HTML
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12552>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:40:58 2011
From: report at bugs.python.org (Felipe Cruz)
Date: Wed, 13 Jul 2011 14:40:58 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1310568058.06.0.0741745228572.issue7484@psf.upfronthosting.co.za>


Felipe Cruz <felipecruz at loogica.net> added the comment:

Can anyone take a loot at those patches?

Do they need more tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:41:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 14:41:22 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310568082.03.0.810649704728.issue12544@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/issue12544>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:45:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 14:45:13 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310568313.72.0.596738428508.issue12545@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> How would it work? The C lseek() takes a signed (64-bit) offset
> as argument, so we would have to call it multiple times anyway.

Python does already call multiple times the same function if the input is larger than the type used by the function. Some examples:

 - mbcs codec: work on chunk on INT_MAX bytes (input size type: Py_ssize_t)
 - zlib: crc32() works on chunk on UINT_MAX bytes (input size type: Py_ssize_t)

We have also functions processing fewer data if the function cannot handle all data: FileIO.write() clamps the buffer size of INT_MAX on Windows for example.

If we call lseek() multiple times, the implementation will depend on the whence value: SEEK_SET will use SEEK_SET and then SEEK_CUR. For SEEK_CUR, all calls can use SEEK_CUR. For SEEK_END... hum? SEEK_END and then SEEK_CUR?

I vote -1 for this feature because I bet that the behaviour of lseek() with an file position > 2^63 or offset > 2^63 highly depend on the platform (kernel, libc) version.

You can implement it in Python for your usecase. I prefer to keep a thin wrapper with an known and reliable behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 16:50:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 14:50:35 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310568635.67.0.452425332232.issue1170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would raising a TypeError if the given argument is a unicode be unacceptable for 2.7?  It would at least make things clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:01:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:01:21 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1310569281.38.0.0268808175276.issue4819@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I spent a few minutes updating the cheatsheet.  I think that the document is an outdated duplicate of random parts of the docs (syntax, man page, library reference, etc.) that?s rather hard to maintain for little benefit.  Is there any evidence that people used it?

I?d like to propose that we delete the file in 2.7 (it?s already gone from 3.2+) and that we start anew on a real cheatsheet, i.e. one or two A4 pages, in HTML and PDF and t-shirts, which are a useful summary of commonly used things.  I think one Python language cheatsheet and one standard library cheatsheet could be useful (one set for 2.7, another one for 3.2).

Regarding process, I?m not sure using a wiki or a non-reST file not included in the real docs is the way to go.  Maybe volunteers could work with the PSF team that?s producing a brochure?  (http://brochure.getpython.info/ ?I discovered it recently, and don?t know at all who works on it and how)

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:06:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:06:30 +0000
Subject: [issue1043134] Add preferred extensions for MIME types
Message-ID: <1310569590.55.0.103935859838.issue1043134@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The proposed patch does not solve the issue.  In the current API, there is no way to do it, so this bug requires a new feature.  I think it would involve a new dict, like preferred_extensions, which would be seeded with default values, like .jpg for image/jpeg and .txt for text/plain, and a few functions/methods to query the dict or add items.

----------
keywords:  -easy, patch
title: mimetypes.guess_extension('text/plain') == '.ksh' ??? -> Add preferred extensions for MIME types

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1043134>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:10:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:10:38 +0000
Subject: [issue11027] Implement sectionxform in configparser
In-Reply-To: <1296139025.05.0.619488294513.issue11027@psf.upfronthosting.co.za>
Message-ID: <1310569838.9.0.665141341918.issue11027@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/issue11027>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:14:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:14:49 +0000
Subject: [issue11470] Flag inappropriate uses of callable class attributes
In-Reply-To: <1299871329.74.0.464645573136.issue11470@psf.upfronthosting.co.za>
Message-ID: <1310570089.21.0.497888737005.issue11470@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Thomas, could you give us a status update?  Maybe I can help with tests or docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11470>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:17:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:17:57 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1310570277.06.0.594577497957.issue1559549@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

How about this case:

  from validmodule import name_with_typo

Do we need one keyword argument module_name and one attribute_name?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:18:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 15:18:36 +0000
Subject: [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1310570316.54.0.846793486386.issue4819@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Another idea might be to have a "cheatsheet" in the official docs with links to the right section and possibly a minimal description.  It would be useful to get a quick overview of the features of the language and use the links to jump to the extended doc without having duplication.
Otherwise the examples could be moved to an external file that gets included both in the cheatsheet and in the official doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4819>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:18:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:18:39 +0000
Subject: [issue11604] Have type(n,b,d) check for type(b[i]) is module
In-Reply-To: <1300500837.93.0.136999770094.issue11604@psf.upfronthosting.co.za>
Message-ID: <1310570319.96.0.977082898969.issue11604@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know if this should be left to lint tools or addressed by CPython itself.  Raymond, do you have an opinion?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11604>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:20:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:20:28 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1310570428.76.0.0592484289846.issue9285@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #8916 for adding standard functionality similar to the decorator module.

----------
components: +Extension Modules -Benchmarks
dependencies: +Move PEP 362 (function signature objects) into inspect
nosy: +eric.araujo
title: A decorator for cProfile and profile modules -> Add a profile decorator to profile and cProfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:24:30 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Wed, 13 Jul 2011 15:24:30 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310558995.81.0.521451419494.issue12545@psf.upfronthosting.co.za>
Message-ID: <CAK=_o0iQEpvgRGb+M9fC7ouyQMBR8KdBdOZnr6JtN7XuR666ZQ@mail.gmail.com>


Kuberan Naganathan <kubiyak at gmail.com> added the comment:

Im most familiar with solaris.  Atleast on solaris lseek interprets its
signed arg as the unsigned value with the same bit pattern.  I cannot be
certain that this is common across other operating systems.
On Jul 13, 2011 8:09 AM, "Antoine Pitrou" <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> In addition I would like the posix_lseek function to accept a value
>> larger than 2^63 as a seek offset
>
> How would it work? The C lseek() takes a signed (64-bit) offset as
argument, so we would have to call it multiple times anyway.
>
> ----------
> nosy: +neologix, pitrou
> versions: +Python 3.2, Python 3.3
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12545>
> _______________________________________

----------
Added file: http://bugs.python.org/file22641/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________
-------------- next part --------------
<p>Im most familiar with solaris.?? Atleast on solaris lseek interprets its signed arg as the unsigned value with the same bit pattern.?? I cannot be certain that this is common across other operating systems.?? </p>
<div class="gmail_quote">On Jul 13, 2011 8:09 AM, &quot;Antoine Pitrou&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br type="attribution">&gt; <br>&gt; Antoine Pitrou &lt;<a href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt; added the comment:<br>
&gt; <br>&gt;&gt; In addition I would like the posix_lseek function to accept a value<br>&gt;&gt; larger than 2^63 as a seek offset<br>&gt; <br>&gt; How would it work? The C lseek() takes a signed (64-bit) offset as argument, so we would have to call it multiple times anyway.<br>
&gt; <br>&gt; ----------<br>&gt; nosy: +neologix, pitrou<br>&gt; versions: +Python 3.2, Python 3.3<br>&gt; <br>&gt; _______________________________________<br>&gt; Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&gt; &lt;<a href="http://bugs.python.org/issue12545">http://bugs.python.org/issue12545</a>&gt;<br>&gt; _______________________________________<br></div>

From report at bugs.python.org  Wed Jul 13 17:26:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Jul 2011 15:26:50 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1310570810.71.0.498417751476.issue9285@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/issue9285>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:27:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:27:29 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1310570849.84.0.664923712985.issue11344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure this is correct for POSIX:
  splitpath('/gparent/parent/') returns ['gparent', 'parent']

/ is a real directory, it should be the ultimate parent of any path IIUC.

On a related note, using ?parent? for the leaf file looks strange to me, I think something like this would make more sense:

 /gparent/parent/somedir/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:30:16 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 13 Jul 2011 15:30:16 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310571016.97.0.217733703049.issue4376@psf.upfronthosting.co.za>


Changes by Vlad Riscutia <riscutiavlad at gmail.com>:


Removed file: http://bugs.python.org/file22627/issue4376_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:31:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 15:31:52 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <CAK=_o0iQEpvgRGb+M9fC7ouyQMBR8KdBdOZnr6JtN7XuR666ZQ@mail.gmail.com>
Message-ID: <1310571047.4043.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Im most familiar with solaris.  Atleast on solaris lseek interprets its
> signed arg as the unsigned value with the same bit pattern.

Only with SEEK_SET, I assume?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:32:15 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 13 Jul 2011 15:32:15 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310571135.11.0.776153553543.issue4376@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

New patch containing unittest that actually tests the feature.

I would appreciate it if someone can try this on a bigendian machine.

----------
Added file: http://bugs.python.org/file22642/issue4376_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:34:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:34:40 +0000
Subject: [issue12412] non defined representation for pwd.struct_passwd
In-Reply-To: <1309017290.05.0.556727126165.issue12412@psf.upfronthosting.co.za>
Message-ID: <1310571280.42.0.615818291227.issue12412@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Actually, I?ve found that there are some structseq?s repr that get tested in the CPython test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12412>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:39:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:39:34 +0000
Subject: [issue3177] implement os.startfile on posix and MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310571574.53.0.696168381056.issue3177@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure we want to copy the Windows startfile call for other OSes.  The os module is designed to wrap system-level calls, masking OS differences (for sendfile, for example) but not going further; it?s up to other modules (like shutil) to build more convenient APIs on top of what os provides.  xdg-open is a program that?s used to open files or URIs, but it does not provide other actions like Windows? startfile does (edit, print, etc.), not is it backed by a system call.  For these reasons, I think it?s inappropriate to implement os.startfile for non-Windows systems.  People can use subprocess to run open or xdg-open.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:40:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:40:23 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1310571623.11.0.850144507497.issue5907@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/issue5907>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:41:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:41:10 +0000
Subject: [issue11698] Improve repr for structseq objects to show named,
	but unindexed fields
In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za>
Message-ID: <1310571670.78.0.881209549662.issue11698@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/issue11698>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:41:54 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Jul 2011 15:41:54 +0000
Subject: [issue3177] implement os.startfile on posix and MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310571714.85.0.469828169553.issue3177@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

+1 on what Eric just said.
See issue 10882 and msg 126049

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:42:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:42:21 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
	tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1310571741.32.0.713043663764.issue1820@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/issue1820>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:44:10 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 13 Jul 2011 15:44:10 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310571850.98.0.482606943274.issue4376@psf.upfronthosting.co.za>


Changes by Vlad Riscutia <riscutiavlad at gmail.com>:


Removed file: http://bugs.python.org/file22642/issue4376_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:44:46 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 13 Jul 2011 15:44:46 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310571886.86.0.957216409685.issue4376@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Changed c_int in tests to c_int32 just to be on the safe side.

----------
Added file: http://bugs.python.org/file22643/issue4376_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:50:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 15:50:19 +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: <1310572219.85.0.20983997285.issue11260@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here are comments on the doc patch.

+Run as a script
+---------------
I?d say ?Command-Line Interface?.

+``smtpd`` is a pluggable RFC 2821-compliant SMTP proxy.
:mod:`smtpd` is also a pluggable etc.

+.. program:: smtpd.py
Strip the .py

+   the ``setuid``
Please use markup like :func:`os.setuid`.

+   flag in order to run ``smtpd`` as a regular user.
Use :mod:`smtpd` or :program:`smtp` (not very important).

+   Turns on verbose debugging prints (to stderr)
Turn on verbose debbugging, which prints to stderr.

+   The concrete SMTP proxy class ``smtpd`` should use to perform its
+   proxying.
Could you add a link to a section of the doc that defines such classes?

+.. option:: localhost:localport
Currently undocumented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Wed Jul 13 17:57:25 2011
From: report at bugs.python.org (Collin Winter)
Date: Wed, 13 Jul 2011 15:57:25 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1310572645.64.0.287496005877.issue9285@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
nosy:  -collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:05:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 16:05:38 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310573138.87.0.941834501524.issue4376@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't like your test because it depends on system endian:

+            if sys.byteorder == "little":
+                struct.menu.spam = 0x000000FF
+            else:
+                struct.menu.spam = 0xFF000000

I would prefer a test creating a structure from a byte string. Something like:
---------------------------
import ctypes

class Nested(ctypes.BigEndianStructure):
    _fields_ = (
        ('x', ctypes.c_uint32),
        ('y', ctypes.c_uint32),
    )

class TestStruct(ctypes.BigEndianStructure):
    _fields_ = (
        ('point', Nested),
    )

data = b'\0\0\0\1\0\0\0\2'
assert len(data) == ctypes.sizeof(TestStruct)
obj = ctypes.cast(data, ctypes.POINTER(TestStruct))[0]
assert obj.point.x == 1
assert obj.point.y == 2
---------------------------

Use b'\1\0\0\0\2\0\0\0' for little endian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:06:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Jul 2011 16:06:25 +0000
Subject: [issue3177] implement os.startfile on posix and MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310573185.56.0.300397851007.issue3177@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

So, unless someone wants to turn this request into ?Add shutil.open?, I?ll close it in a few days.  (I haven?t found the original discussion; if someone could add a link to the archives on mail.python.org or copy relevant quotes, it could help.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:06:26 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 13 Jul 2011 16:06:26 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1310573186.94.0.402766508713.issue10224@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:07:51 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 13 Jul 2011 16:07:51 +0000
Subject: [issue2506] Line tracing of continue after always-taken if is
	incorrect
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1310573271.72.0.662168239803.issue2506@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

Since the main argument for not fixing this bug seems to be that it doesn't affect many users, it seems like I should comment here that the issue is affecting me.  A recently proposed addition to Twisted gets bitten by this case, resulting in a report of less than full test coverage when in fact the tests do exercise every line and branch of the change.

Perhaps it is too hard to add and maintain a no-optimizations feature for Python (although I agree with Ned that this would be a useful feature for many reasons, not just to fix this bug).  There are other possible solutions to the issue of inaccurate coverage reports though.

For example, Python could provide an API for determining which lines have code that might be executed.  coverage.py (and the stdlib trace.py) currently use the code object's lnotab to decide which lines might be executable.  Maybe that should omit "continue" lines that get jumped over.  If the line will never execute, it seems there is no need to have it in the lnotab.

Using the lnotab is something of a hack though, so it might also make sense to leave it alone but introduce an API to get the same information, but corrected for whatever peephole optimizations the interpreter happens to have.

As far as the "not a bug" arguments go, I don't think it matters much whether you ultimately decide to call it a bug or a feature request.  It *is* clearly a useful feature to some people though, and rejecting the requested behavior as "not a bug" doesn't help anyone.  So call it a feature request if that makes it more palletable. :)

----------
nosy: +exarkun
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:12:24 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 13 Jul 2011 16:12:24 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1310573544.35.0.42053988035.issue1559549@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:14:12 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 13 Jul 2011 16:14:12 +0000
Subject: [issue11470] Flag inappropriate uses of callable class attributes
In-Reply-To: <1299871329.74.0.464645573136.issue11470@psf.upfronthosting.co.za>
Message-ID: <1310573652.94.0.996040798396.issue11470@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11470>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:22:16 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 13 Jul 2011 16:22:16 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310574136.66.0.669309263934.issue4376@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

But if you set raw memory to let's say b'\0\0\0\1', when you look at the c_int value afterwards, won't it be different on little endian and big endian machines?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:23:40 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 13 Jul 2011 16:23:40 +0000
Subject: [issue3177] implement os.startfile on posix and MacOSX
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310574220.27.0.826758939725.issue3177@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Eric, I have no problem with this function being placed in `shutil` instead of `os`, as long as it's implemented and it's in the standard library, and people don't have to use subprocess to run open or xdg-open themselves as I currently do.

So I have no problem with renaming this bug to "Add shutil.open".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:24:31 2011
From: report at bugs.python.org (Jake)
Date: Wed, 13 Jul 2011 16:24:31 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310574271.01.0.519775272101.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 Jul 13 18:26:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 16:26:27 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310574387.89.0.586574142872.issue4376@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> But if you set raw memory to let's say b'\0\0\0\1',
> when you look at the c_int value afterwards, won't it
> be different on little endian and big endian machines?

A big endian structure is supposed to read and write memory in the... big endian order, not in the host endian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:35:49 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 13 Jul 2011 16:35:49 +0000
Subject: [issue2506] Line tracing of continue after always-taken if is
	incorrect
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1310574949.61.0.854419973932.issue2506@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:39:07 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 13 Jul 2011 16:39:07 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310575147.38.0.0860639949157.issue4376@psf.upfronthosting.co.za>


Changes by Vlad Riscutia <riscutiavlad at gmail.com>:


Removed file: http://bugs.python.org/file22643/issue4376_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:40:09 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 13 Jul 2011 16:40:09 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310575209.65.0.668858064221.issue4376@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

You're right. I was busy swapping bytes in my head and missed that :)

----------
Added file: http://bugs.python.org/file22644/issue4376_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:41:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 16:41:10 +0000
Subject: [issue12552] email.MIMEText overide BASE64 for utf8 charset
In-Reply-To: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>
Message-ID: <1310575270.56.0.271861906627.issue12552@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This should do what you want:

  from email import charset
  charset.add_charset('utf-8', charset.SHORTEST, charset.QP)

This will override the default handling of utf-8 (which is BASE64, as you note).

If this doesn't solve your problem please reopen the issue.

It is a valid feature request (for 3.3) to have a way to make this '8bit'.  I think I'll open an issue for that.

----------
assignee:  -> r.david.murray
components: +Library (Lib) -None
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: email.MIMEText overide BASE64 on TEXT/HTML -> email.MIMEText overide BASE64 for utf8 charset

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12552>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:47:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 16:47:26 +0000
Subject: [issue12553] email should default to 8bit CTE unless
	policy.must_be_7bit is set
In-Reply-To: <1310575646.04.0.928731351527.issue12553@psf.upfronthosting.co.za>
Message-ID: <1310575646.04.0.928731351527.issue12553@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Most MTA/MTUs these days can handle 8bit just fine.  I think that the CTE for MIMEText parts should default to 8bit unless policy.must_be_7bit is set.  This will require adding support for this CTE to Charset.  The Policy docs imply that this is already the case, but it is not true for MIMEText objects.

----------
components: Library (Lib)
messages: 140287
nosy: Blame-me.Jaillie, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email should default to 8bit CTE unless policy.must_be_7bit is set
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12553>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:50:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 16:50:51 +0000
Subject: [issue12552] email.MIMEText overide BASE64 for utf8 charset
In-Reply-To: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>
Message-ID: <1310575851.35.0.388603338373.issue12552@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Opened issue 12553 for the 8bit feature request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12552>
_______________________________________

From report at bugs.python.org  Wed Jul 13 18:58:55 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Wed, 13 Jul 2011 16:58:55 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310571047.4043.0.camel@localhost.localdomain>
Message-ID: <CAK=_o0htMjFjEr1MMfR7NzFEMvDW-smGF_steVLbTJn9n_8r1A@mail.gmail.com>


Kuberan Naganathan <kubiyak at gmail.com> added the comment:

I did some testing on this.  Solaris seems to treat files as a large
circular buffer of size 2^64 with respect to seeks in the /proc file system
address space file. No error results with seeks of greater than 2^63 with
any of SEEK_SET, SEEK_CUR, SEEK_END.  This is not true of a regular file
where I get errno=22 when seeking to an offset greater than or equal to
2^63.

So even on solaris the behavior seems to be filesystem dependent.

----------
Added file: http://bugs.python.org/file22645/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________
-------------- next part --------------
<p>I did some testing on this.?? Solaris seems to treat files as a large circular buffer of size 2^64 with respect to seeks in the /proc file system address space file. No error results with seeks of greater than 2^63 with any of SEEK_SET, SEEK_CUR, SEEK_END.?? This is not true of a regular file where I get errno=22 when seeking to an offset greater than or equal to 2^63.?? </p>

<p>So even on solaris the behavior seems to be filesystem dependent.?? </p>

From report at bugs.python.org  Wed Jul 13 19:04:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Jul 2011 17:04:01 +0000
Subject: [issue2506] Add mechanism to diasable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1310576641.34.0.806544194311.issue2506@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think supporters of this feature request should take discussion to python-ideas to try to gather more support. The initial post should summarize reasons for the request, possible implementations, and the counter-arguments of Raymond.

----------
title: Line tracing of continue after always-taken if is incorrect -> Add mechanism to diasable optimizations
type: behavior -> feature request
versions: +Python 3.3 -Python 2.3, Python 2.4, Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Wed Jul 13 19:33:10 2011
From: report at bugs.python.org (Blame-me Jaillie)
Date: Wed, 13 Jul 2011 17:33:10 +0000
Subject: [issue12552] email.MIMEText overide BASE64 for utf8 charset
In-Reply-To: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>
Message-ID: <1310578390.48.0.378624489634.issue12552@psf.upfronthosting.co.za>


Blame-me Jaillie <darkshado.1972 at gmail.com> added the comment:

Very much obliged to you - as pointed out by R David Murray:

  from email import charset
  charset.add_charset('utf-8', charset.SHORTEST, charset.QP)

This works exactly as expected - but to expand for anyone else who happens across this, this will result in quoted printable transfer encoding. Removing the final 'charset.QP' results in (for me) the desired 7bit. 

Again, sincere thanks to R David Murray for pointing me in the correct way, and making my first experience with a Python 'issue' painless and flame free. Really appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12552>
_______________________________________

From report at bugs.python.org  Wed Jul 13 19:53:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 17:53:09 +0000
Subject: [issue11183] Finer-grained exceptions for the ssl module
In-Reply-To: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>
Message-ID: <1310579589.5.0.356187264826.issue11183@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note: the ERR_GET_REASON() macro helps get a more precise explanation of an error. We could add a reason attribute to raised exceptions, and also provide a mnemonic-integer mapping.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11183>
_______________________________________

From report at bugs.python.org  Wed Jul 13 19:55:13 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Wed, 13 Jul 2011 17:55:13 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310579713.58.0.112061225298.issue12551@psf.upfronthosting.co.za>


Jacek Konieczny <jajcus at jajcus.net> added the comment:

Here is a patch, ready for review. Seems to work, though I still need to check it with some other implementation.

I have chosen not to expose another three OpenSSL functions (SSL_get_finished, SSL_get_peer_finished, SSL_session_reused), but provide API just for getting the channel binding. If OpenSSL provides a better API some day (gnutls already has a dedicated function), we can use that.

The method added to SSLSocket - get_channel_binding() currently can return only the 'tls-unique' channel binding type, but can be easily extended for other types, which also may be easier to get from the C module.

----------
keywords: +patch
Added file: http://bugs.python.org/file22646/tls_channel_binding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Wed Jul 13 20:02:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 18:02:47 +0000
Subject: [issue12552] email.MIMEText overide BASE64 for utf8 charset
In-Reply-To: <1310567855.09.0.336758038294.issue12552@psf.upfronthosting.co.za>
Message-ID: <1310580167.81.0.960706626333.issue12552@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Good point.  In 2.x that will work, and will give you the 8bit CTE at need, as long as you pass encoded text to MIMEText (as opposed to unicode...which it doesn't really handle correctly if I recall right).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12552>
_______________________________________

From report at bugs.python.org  Wed Jul 13 20:05:58 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 13 Jul 2011 18:05:58 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1310580358.54.0.186895521914.issue12545@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/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 13 20:52:13 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Jul 2011 18:52:13 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <1310583133.74.0.202669041564.issue12549@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

What version of OS X are you running this on?  10.7 perhaps?  AFAIK, uname has always reported 'i386' for Intel machines.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 21:01:49 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 13 Jul 2011 19:01:49 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310583709.93.0.0790218147655.issue12551@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/issue12551>
_______________________________________

From report at bugs.python.org  Wed Jul 13 21:40:31 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 19:40:31 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310583133.74.0.202669041564.issue12549@psf.upfronthosting.co.za>
Message-ID: <CAGT-NP3B45hD=cCbCRhs_io-hwNVvQNnTqEkfTY-UC=cCFGmdw@mail.gmail.com>


Davide Rizzo <sorcio at gmail.com> added the comment:

No, it's 10.6.8. Now that I think of it I updated from 10.6.7
recently. But I have no 10.6.7 x86_64 bit machine where to test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 21:40:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 19:40:48 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1310586048.45.0.145746205938.issue7559@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Michael, if you have no objection to this patch I'm willing to commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Wed Jul 13 21:44:23 2011
From: report at bugs.python.org (Calvin Spealman)
Date: Wed, 13 Jul 2011 19:44:23 +0000
Subject: [issue12554] Failed imports clean up module, but not sub modules
In-Reply-To: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>
Message-ID: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>


New submission from Calvin Spealman <ironfroggy at gmail.com>:

I came across this behavior when it was related to the shadowing of a small typo bug and took me forever to find. In my case, the original error was shadowed in a way that is unrelated to this bug, but lead to the module being imported twice (because it was removed when it failed the first time) and then the second import caused a completely unexpected error, because the state of the submodules conflicted with the import-time logic of the top-level package.

I think when a module fails to load, all of its sub-modules should be removed from sys.modules, not just itself.

calvin at willow-delta:/tmp$ mkdir foo/
calvin at willow-delta:/tmp$ cat >> foo/__init__.py
import foo.bar
1/0
calvin at willow-delta:/tmp$ cat >> foo/bar.py
name = "bar"
calvin at willow-delta:/tmp$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "foo/__init__.py", line 2, in <module>
    1/0
ZeroDivisionError: integer division or modulo by zero
>>> import sys
>>> sys.modules['foo.bar']
<module 'foo.bar' from 'foo/bar.py'>
>>>

----------
components: Interpreter Core
messages: 140298
nosy: Calvin.Spealman
priority: normal
severity: normal
status: open
title: Failed imports clean up module, but not sub modules
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12554>
_______________________________________

From report at bugs.python.org  Wed Jul 13 21:48:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jul 2011 19:48:27 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <E1Qh5Q2-00051h-3O@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 72e73fa03124 by Victor Stinner in branch '3.2':
Close #4376: ctypes now supports nested structures in a endian different than
http://hg.python.org/cpython/rev/72e73fa03124

New changeset 637210b9d054 by Victor Stinner in branch 'default':
(merge 3.2) Close #4376: ctypes now supports nested structures in a endian
http://hg.python.org/cpython/rev/637210b9d054

New changeset a9d0fab19d5e by Victor Stinner in branch '2.7':
Close #4376: ctypes now supports nested structures in a endian different than
http://hg.python.org/cpython/rev/a9d0fab19d5e

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 21:51:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 19:51:38 +0000
Subject: [issue12554] Failed imports clean up module, but not sub modules
In-Reply-To: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>
Message-ID: <1310586698.2.0.277159678565.issue12554@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That can't be done.  If an import fails, it fails.  But if it succeeds, the module is loaded, and there is no reason to unload it.  After all, import in python is idempotent (doing it a second time has no effect other than adding the name to the local namespace).  So the import in the module that failed to load may not be the first, and unloading it would break other modules using it.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12554>
_______________________________________

From report at bugs.python.org  Wed Jul 13 22:20:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 20:20:53 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1310588453.07.0.514159532571.issue4376@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited your fix, thanks Vlad!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Jul 13 22:25:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Jul 2011 20:25:46 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <1310588746.94.0.901658290066.issue12549@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I have never seen this failure on any Apple x86_64 running 10.x including 10.6.8.  Could you please report what Mac model you are running on and the output from running the following:

$ uname -m
$ /path/to/your/python
Python 3.2.1 (v3.2.1:ac1f7e5c0510, Jul  9 2011, 01:03:53) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxsize
9223372036854775807
>>> import platform
>>> platform.mac_ver()
('10.6.8', ('', '', ''), 'i386')
>>> platform._mac_ver_xml()
('10.6.8', ('', '', ''), 'i386')
>>> platform._mac_ver_gestalt()  # a bug!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/platform.py", line 761, in _mac_ver_gestalt
    return release,versioninfo,machine
>>> import os
>>> os.uname()
('Darwin', 'fimt.baybryj.net', '10.8.0', 'Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386', 'i386')

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 22:29:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Jul 2011 20:29:39 +0000
Subject: [issue2506] Add mechanism to diasable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1310588979.43.0.534005679499.issue2506@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Choose pydev if you want. Discussion there is *usually* (but definitely not always) more focused on implementation of uncontroversial changes. I am pretty much +-0 on the issue, though Jean-Paul's post seems to add to the + side arguments that might be persuasive to others also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Wed Jul 13 22:29:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Jul 2011 20:29:41 +0000
Subject: [issue2506] Add mechanism to diasable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1310588981.42.0.919476428015.issue2506@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Choose pydev if you want. Discussion there is *usually* (but definitely not always) more focused on implementation of uncontroversial changes. I am pretty much +-0 on the issue, though Jean-Paul's post seems to add to the + side arguments that might be persuasive to others also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Wed Jul 13 22:32:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Jul 2011 20:32:41 +0000
Subject: [issue2506] Add mechanism to diasable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1310589161.9.0.959052001654.issue2506@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg140304

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Wed Jul 13 22:51:48 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 13 Jul 2011 20:51:48 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <1310590308.5.0.794197301353.issue12549@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

I first saw it failing on 3.3 while testing for another bug, then run the test on other versions including 2.7 and it always fails. System Python 2.6 does NOT fail, but it has no _mac_ver_xml().

This is a MacBook Pro 13" with Intel Core i5.

--------------------
$ uname -m
x86_64
$ ./python.exe 
Python 3.3.0a0 (default:e0cd35660ae9, Jul 13 2011, 11:02:57) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
[63386 refs]
>>> sys.maxsize
9223372036854775807
[63389 refs]
>>> import platform
[65649 refs]
>>> platform.mac_ver()
('10.6.8', ('', '', ''), 'x86_64')
[69688 refs]
>>> platform._mac_ver_xml()
('10.6.8', ('', '', ''), 'x86_64')
[69733 refs]
>>> platform._mac_ver_gestalt()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/davide/cpython/Lib/platform.py", line 682, in _mac_ver_gestalt
    return release,versioninfo,machine
NameError: global name 'versioninfo' is not defined
[69809 refs]
>>> import os
[69811 refs]
>>> os.uname()
('Darwin', 'Brude.local', '10.8.0', 'Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64', 'x86_64')
[69814 refs]

--------------------



The following is with System Python 2.6 on the same OS:
--------------------
Python 2.6.1 (r261:67515, Aug  2 2010, 20:10:18) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.mac_ver()
('10.6.8', ('', '', ''), 'i386')
>>> import sys
>>> sys.maxsize
9223372036854775807

--------------------


Then Python 2.7 from www.python.org:
--------------------
Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxsize
9223372036854775807
>>> import platform
>>> platform.mac_ver()
('10.6.8', ('', '', ''), 'x86_64')
>>> platform._mac_ver_xml()
('10.6.8', ('', '', ''), 'x86_64')
>>> platform._mac_ver_gestalt()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/platform.py", line 768, in _mac_ver_gestalt
    return release,versioninfo,machine
NameError: global name 'versioninfo' is not defined

--------------------

If you need any more info feel free to ask.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 22:57:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Jul 2011 20:57:16 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <1310590636.26.0.720779634902.issue12549@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for running that.  I guess the significant difference is having an i5 processor.  We'll need to fix it.

----------
assignee: ronaldoussoren -> ned.deily
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 23:05:36 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jul 2011 21:05:36 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1310591136.76.0.71941639967.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

No, we don't need attribute_name as that is getting too specific. Your example is simply importing validmodule.name_with_typo which happens to possibly be an attribute on the module instead of another module or subpackage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Wed Jul 13 23:21:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Jul 2011 21:21:10 +0000
Subject: [issue9592] Limitations in objects returned by multiprocessing Pool
In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za>
Message-ID: <1310592070.22.0.828706191974.issue9592@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

A recent test_rapid_restart hang:

[ 14/357] test_multiprocessing
Timeout (1:00:00)!
Thread 0xb18c4b70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 185 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 376 in _handle_results
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb20c5b70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 185 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 335 in _handle_tasks
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb28c6b70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 326 in _handle_workers
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb30c7b70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 185 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb38c8b70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 185 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb40c9b70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 185 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb48cab70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 185 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 102 in worker
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb50cbb70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 411 in _recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 432 in _recv_bytes
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 275 in recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 376 in _handle_results
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb58ccb70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 185 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 335 in _handle_tasks
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb60cdb70:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 326 in _handle_workers
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 690 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 737 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 710 in _bootstrap

Thread 0xb76a36c0:
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 411 in _recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 432 in _recv_bytes
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 241 in recv_bytes
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 759 in recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/managers.py", line 762 in _callmethod
  File "<string>", line 2 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_multiprocessing.py", line 1417 in test_rapid_restart
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/case.py", line 386 in _executeTestPart
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/case.py", line 441 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/case.py", line 493 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 105 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 105 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 105 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/runner.py", line 168 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/support.py", line 1260 in _run_suite
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/support.py", line 1286 in run_unittest
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_multiprocessing.py", line 2228 in test_main
  File "./Lib/test/regrtest.py", line 1070 in runtest_inner
  File "./Lib/test/regrtest.py", line 861 in runtest
  File "./Lib/test/regrtest.py", line 669 in main
  File "./Lib/test/regrtest.py", line 1648 in <module>
make: *** [buildbottest] Error 1

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/389/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9592>
_______________________________________

From report at bugs.python.org  Wed Jul 13 23:40:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jul 2011 21:40:30 +0000
Subject: [issue12550] regrtest: register SIGALRM signal using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <E1Qh7AN-0007Tk-LO@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 39873557ff4f by Victor Stinner in branch 'default':
Issue #12550: Add chain optional argument to faulthandler.register()
http://hg.python.org/cpython/rev/39873557ff4f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12550>
_______________________________________

From report at bugs.python.org  Wed Jul 13 23:49:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jul 2011 21:49:44 +0000
Subject: [issue12550] regrtest: register SIGALRM signal using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <E1Qh7JO-0008Uu-Pt@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 30f91fbfc8b3 by Victor Stinner in branch 'default':
Issue #12550: regrtest displays the Python traceback on SIGALRM or SIGUSR1
http://hg.python.org/cpython/rev/30f91fbfc8b3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12550>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:01:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:01:24 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310594484.14.0.0389267839547.issue12551@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you, this looks mostly good.
A couple of nits:

+#if OPENSSL_VERSION_NUMBER >= 0x0090500fL
+# define HAVE_OPENSSL_FINISHED 1
+#else
+# undef HAVE_OPENSSL_FINNISHED
+#endif

you have a typo in the #undef, also it would be more logical to have
  # define HAVE_OPENSSL_FINISHED 0
instead.

_ssl.c will not compile if OpenSSL is too old, because you lack some #if's (or #ifdef's) around PySSL_tls_unique_cb.

Also, it would be nice to expose the availability of tls-unique as a public constant, as we already do for "ssl.HAS_SNI". ssl.HAS_TLS_UNIQUE?

Similarly, you need to skip some of the tests when the functionality isn't available.
And I think get_channel_binding() should raise NotImplementedError in that case.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:10:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jul 2011 22:10:37 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <E1Qh7dc-0001kx-20@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0a53a978a160 by Ned Deily in branch '2.7':
Issue #12549: Correct test_platform to not fail when OS X returns 'x86_64'
http://hg.python.org/cpython/rev/0a53a978a160

New changeset d050c8c9a3b3 by Ned Deily in branch '3.2':
Issue #12549: Correct test_platform to not fail when OS X returns 'x86_64'
http://hg.python.org/cpython/rev/d050c8c9a3b3

New changeset 0025ce38fbd0 by Ned Deily in branch 'default':
Issue #12549: Correct test_platform to not fail when OS X returns 'x86_64'
http://hg.python.org/cpython/rev/0025ce38fbd0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:13:12 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Jul 2011 22:13:12 +0000
Subject: [issue12549] test_platform test_mac_ver fails on Darwin x86_64
In-Reply-To: <1310550563.79.0.541656133968.issue12549@psf.upfronthosting.co.za>
Message-ID: <1310595192.45.0.616586925429.issue12549@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12549>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:15:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jul 2011 22:15:17 +0000
Subject: [issue12536] lib2to3 BaseFix class creates un-needed loggers leading
	to refleaks
In-Reply-To: <1310407101.06.0.821103833142.issue12536@psf.upfronthosting.co.za>
Message-ID: <E1Qh7i7-00028o-VS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dd004e85e299 by Vinay Sajip in branch 'default':
Closes #12536: Unused logger removed from lib2to3.
http://hg.python.org/cpython/rev/dd004e85e299

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12536>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:19:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:19:32 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I now have a working PEP 3151 implementation, working on various platforms (tested on Linux, Windows, FreeBSD and OpenIndiana buildbots).

The implementation has all the semantic changes and additions in PEP 3151. It still lacks the deprecation mechanism mentioned in "step 1" of the PEP.

The implementation is at http://hg.python.org/features/pep-3151/ in the branch named "pep-3151".

----------
assignee: pitrou
components: Interpreter Core
messages: 140314
nosy: barry, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: PEP 3151 implementation
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:19:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:19:46 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310595586.79.0.481480924993.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
hgrepos: +41

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:20:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:20:47 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310595647.58.0.689844754128.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22647/cac46b853098.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:28:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:28:51 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310596131.29.0.795341196973.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file22647/cac46b853098.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:32:58 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 13 Jul 2011 22:32:58 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310596378.21.0.1177066916.issue12555@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:35:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:35:33 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310596533.75.0.761134533101.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file22648/d305942126b6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:39:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 22:39:01 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310596741.6.0.0942417102851.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I'm sorry for the filenames. I'm using the "create patch" feature in the hope that a code review is possible through the Rietveld integration :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 00:54:43 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 13 Jul 2011 22:54:43 +0000
Subject: [issue12554] Failed imports clean up module, but not sub modules
In-Reply-To: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>
Message-ID: <1310597683.78.0.747217793901.issue12554@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

But it is curious that the submodules were added to sys.modules even though the package failed to import.

----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12554>
_______________________________________

From report at bugs.python.org  Thu Jul 14 01:04:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 23:04:38 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1310598278.48.0.105800311121.issue665194@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, here is a new patch proposal.  As suggested by Alexander, it adds two functions to email.utils: format_datetime and parsedate_to_datetime.  Adding these does not require having localtime.  In fact, with this patch you can get an aware datetime representing email's current best guess at localtime by doing:

   dt = parsedate_to_datetime(formatdate(localtime=True))

Reviews welcome, but this is simple enough I'll probably just commit it if no one objects.

----------
assignee: belopolsky -> r.david.murray
Added file: http://bugs.python.org/file22649/util_datetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665194>
_______________________________________

From report at bugs.python.org  Thu Jul 14 01:13:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Jul 2011 23:13:53 +0000
Subject: [issue12554] Failed imports clean up module, but not sub modules
In-Reply-To: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>
Message-ID: <1310598833.46.0.358697480705.issue12554@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, that's exactly my point.  The loading of a module into sys.modules is a separate issue from the creation of a pointer to that module in the local name space.  Once the former succeeds, it has succeeded and won't be done again.  When the module that did the import fails to complete, *it* is cleaned up, which cleans up the pointer in the local name space, but that doesn't (by design) affect sys.modules.

It's not all that dissimilar to what would happen if you had top-level code in your module that opened and wrote to a file.  If an exception later in the module code causes it to fail to load, the file it created would not be deleted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12554>
_______________________________________

From report at bugs.python.org  Thu Jul 14 01:40:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 23:40:36 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310600436.05.0.17366845141.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file22650/9bb6b71f172d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 01:44:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jul 2011 23:44:07 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310600647.66.0.553775063239.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file22648/d305942126b6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 02:37:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 00:37:21 +0000
Subject: [issue12550] regrtest: register SIGALRM signal using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <1310603841.58.0.735102113971.issue12550@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch doesn't work: the traceback is not printed:
--------------------------
$ ./python -m test -v -u network -F test_threadsignals
(...)
[106] test_socketserver
(...)
test_UnixStreamServer (test.test_socketserver.SocketServerTest) ... creating server
ADDR = /tmp/unix_socket.wuwy8y
CLASS = <class 'socketserver.UnixStreamServer'>
server running
test client 0
test client 1
test client 2
waiting for server
done
ok
test_shutdown (test.test_socketserver.SocketServerTest) ... Alarm clock: 14
--------------------------

SocketServerTest uses a timeout of 20 seconds implemented using signal.alarm(). I suppose that the timeout is too small for this very slow buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12550>
_______________________________________

From report at bugs.python.org  Thu Jul 14 03:28:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 01:28:58 +0000
Subject: [issue12554] Failed imports clean up module, but not sub modules
In-Reply-To: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>
Message-ID: <1310606938.7.0.203712329856.issue12554@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In fact, to hopefully make perfectly clear what is going on here, let me demonstrate that *any* executable statement in the module that fails to load is executed if it occurs before the error that causes the load failure:

    rdmurray at hey:~/python/p32>cat temp.py
    import os

    print('foo:', hasattr(os, 'foo'))

    try:
        import temp2
    except AttributeError:
        print('attribute error')

    print('temp2:', 'temp2' in globals())
    print('foo:', hasattr(os, 'foo'))
    rdmurray at hey:~/python/p32>cat temp2.py
    import os

    os.foo = 2
    os.bar

    rdmurray at hey:~/python/p32>./python temp.py
    foo: False
    attribute error
    temp2: False
    foo: True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12554>
_______________________________________

From report at bugs.python.org  Thu Jul 14 03:55:21 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Jul 2011 01:55:21 +0000
Subject: [issue8916] Move PEP 362 (function signature objects) into inspect
In-Reply-To: <1275795560.39.0.398177747359.issue8916@psf.upfronthosting.co.za>
Message-ID: <1310608521.44.0.655536167099.issue8916@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8916>
_______________________________________

From report at bugs.python.org  Thu Jul 14 05:20:15 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Jul 2011 03:20:15 +0000
Subject: [issue12554] Failed imports clean up module, but not sub modules
In-Reply-To: <1310586263.14.0.144683029757.issue12554@psf.upfronthosting.co.za>
Message-ID: <1310613615.84.0.923104870496.issue12554@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Yeah, I missed the line where he imported foo.bar in "foo/__init__.py", and thought something else was going on.
  
"foo/__init__.py" does not have to finish importing (just has to be on sys.modules) at the point foo.bar is imported.  So foo.bar would be completely imported before the "1/0" expression was evaluated, and you are exactly right, David.

Sorry for adding to the confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12554>
_______________________________________

From report at bugs.python.org  Thu Jul 14 06:42:12 2011
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 14 Jul 2011 04:42:12 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310618532.67.0.586345662483.issue5505@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I get this on Linux with ^D

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Thu Jul 14 09:15:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 14 Jul 2011 07:15:55 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1310627755.45.0.158603921709.issue12287@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Brian, any comment about the Windows part (see Victor's message, http://bugs.python.org/issue12287#msg138137) ?

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Thu Jul 14 09:17:08 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Thu, 14 Jul 2011 07:17:08 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310627828.16.0.705829600599.issue12551@psf.upfronthosting.co.za>


Jacek Konieczny <jajcus at jajcus.net> added the comment:

Thanks for the quick review. Most of the problems are my oversights.

I am not sure about that:
> And I think get_channel_binding() should raise NotImplementedError in that case.

As the method is supposed to be extensible and 'tls-unique' may be just one of possible channel-binding types, then I think the same exception should be raised in case 'tls-unique' is requested and not implemented and when other, currently not implemented, channel binding type is requested. The get_channel_binding() method itself is always implemented, that is why I wonder if 'ValueError' is no better. Or 'NotImplementedError' for both 'tls-unique not implemented' and 'unknown channel binding'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Thu Jul 14 12:30:07 2011
From: report at bugs.python.org (yuriy_levchenko)
Date: Thu, 14 Jul 2011 10:30:07 +0000
Subject: [issue12548] Add suport native Functor
In-Reply-To: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>
Message-ID: <1310639407.75.0.0490402811442.issue12548@psf.upfronthosting.co.za>


yuriy_levchenko <levchenko.yuriy.vladimirovich at gmail.com> added the comment:

http://www.python.org/dev/peps/pep-0309/#note

--------------------------------------------------------------------

Abandoned Syntax Proposal
 
I originally suggested the syntax fn@(*args, **kw), meaning the same as partial(fn, *args, **kw).
 
The @ sign is used in some assembly languages to imply register indirection, and the use here is also a kind of indirection. f@(x) is not f(x), but a thing that becomes f(x) when you call it.
 
It was not well-received, so I have withdrawn this part of the proposal. In any case, @ has been taken for the new decorator syntax

--------------------------------------------------------------------


Maybe change '@' -> '%'

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12548>
_______________________________________

From report at bugs.python.org  Thu Jul 14 12:44:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 10:44:31 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310640271.38.0.681626576468.issue5505@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I get this on Linux with ^D

With which Python version? Did you try Python 3.3 (development version)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Thu Jul 14 13:24:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jul 2011 11:24:15 +0000
Subject: [issue12548] Add suport native Functor
In-Reply-To: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>
Message-ID: <1310642655.55.0.44434320621.issue12548@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Using the func%(args) syntax is not possible because
fab = foo%(1,2)
is equivalent to
fab = foo.__mod__((1,2))

It might actually be possible to overload the % operator to make something that looks like your proposed syntax (without changing the actual Python syntax), but it still look hackish to me.
(We are also moving away from the % overload used by strings for the formatting in favor of the .format() method.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12548>
_______________________________________

From report at bugs.python.org  Thu Jul 14 14:11:18 2011
From: report at bugs.python.org (Srikanth S)
Date: Thu, 14 Jul 2011 12:11:18 +0000
Subject: [issue6942] email.generator.Generator memory consumption
In-Reply-To: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>
Message-ID: <1310645478.24.0.446551215257.issue6942@psf.upfronthosting.co.za>


Changes by Srikanth S <sriksubr at gmail.com>:


----------
nosy: +srikanths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6942>
_______________________________________

From report at bugs.python.org  Thu Jul 14 14:23:11 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 14 Jul 2011 12:23:11 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1310646191.92.0.740165007247.issue7559@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

My thinking on this has evolved a bit. Changing an import error into an attribute error is just a bad api. We should just fix the bad api.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7559>
_______________________________________

From report at bugs.python.org  Thu Jul 14 14:29:25 2011
From: report at bugs.python.org (Srikanth S)
Date: Thu, 14 Jul 2011 12:29:25 +0000
Subject: [issue1670765] email.Generator: no header wrapping for
	multipart/signed
Message-ID: <1310646565.74.0.768962029142.issue1670765@psf.upfronthosting.co.za>


Changes by Srikanth S <sriksubr at gmail.com>:


----------
nosy: +srikanths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1670765>
_______________________________________

From report at bugs.python.org  Thu Jul 14 14:29:41 2011
From: report at bugs.python.org (Srikanth S)
Date: Thu, 14 Jul 2011 12:29:41 +0000
Subject: [issue968430] error flattening complex smime signed message
Message-ID: <1310646581.93.0.410217125367.issue968430@psf.upfronthosting.co.za>


Changes by Srikanth S <sriksubr at gmail.com>:


----------
nosy: +srikanths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue968430>
_______________________________________

From report at bugs.python.org  Thu Jul 14 14:34:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 12:34:35 +0000
Subject: [issue12548] Add suport native Functor
In-Reply-To: <1310549728.28.0.863675817161.issue12548@psf.upfronthosting.co.za>
Message-ID: <1310646875.82.0.853878453823.issue12548@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12548>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:19:33 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Thu, 14 Jul 2011 13:19:33 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310649573.69.0.687788912764.issue12551@psf.upfronthosting.co.za>


Jacek Konieczny <jajcus at jajcus.net> added the comment:

This is patch updated according to your suggestions, including raising NotImplementedError when 'tls-unique' is not available and with the ssl.HAS_TLS_UNIQUE constant added.

It also includes an important fix to the data retrieval logic (one condition had to be reverted). 

Now the code is proven to work, by testing with another implementation (SCRAM-SHA-1-PLUS authentication in Isode M-Link 15.1a0).

A alternative patch version will follow.

----------
Added file: http://bugs.python.org/file22651/tls_channel_binding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:21:00 2011
From: report at bugs.python.org (Sergei Lebedev)
Date: Thu, 14 Jul 2011 13:21:00 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>


New submission from Sergei Lebedev <superbobry at gmail.com>:

Current `mmap` implementation raises a ValueError if a sum of offset and length exceeds file size, as reported by `fstat`. While perfectly valid for most use-cases, it doesn't work for "special" files, for example:

>>> with open("/proc/sys/debug/exception-trace", "r+b") as f:
...     mmap.mmap(f.fileno(), 0)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ValueError: mmap offset is greater than file size

Same goes for almost any other /proc file, because most of them have S_ISREG() == True and st_size = 0.

How about adding a keyword argument to `mmap.mmap()`, which disables fstat-based size checks?

----------
components: Library (Lib)
messages: 140330
nosy: superbobry
priority: normal
severity: normal
status: open
title: Disable size checks in mmap.mmap()
type: feature request
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:26:03 2011
From: report at bugs.python.org (Jacek Konieczny)
Date: Thu, 14 Jul 2011 13:26:03 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310649963.32.0.0189334744199.issue12551@psf.upfronthosting.co.za>


Jacek Konieczny <jajcus at jajcus.net> added the comment:

This patch is functionally equivalent, but advertises 'tls-unique' support in a bit different way.

HAS_TLS_UNIQUE is not exposed in the python 'ssl' module, instead a list 'CHANNEL_BINDING_TYPES' is provided (empty when 'tls-unique' is not supported). get_channel_binding raises ValueError if the argument is not on this list. This way the API can be extended to other channel binding types without adding new constants or functions. Adding a new channel binding type would not need any modifications in the API client code (if it is designed to use arbitrary cb types).

----------
Added file: http://bugs.python.org/file22652/tls_channel_binding_alt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:29:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Jul 2011 13:29:31 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1310650171.7.0.547054675272.issue10403@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/issue10403>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:41:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jul 2011 13:41:11 +0000
Subject: [issue12250] regrtest: make --timeout explicit
In-Reply-To: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>
Message-ID: <E1QhMA9-0003N6-Lc@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d3cebbd500aa by Victor Stinner in branch '2.7':
Issue #12250: test_socketserver uses a timeout of 60 seconds instead of 20
http://hg.python.org/cpython/rev/d3cebbd500aa

New changeset 05dfed82457a by Victor Stinner in branch '3.2':
Issue #12250: test_socketserver uses a timeout of 60 seconds instead of 20
http://hg.python.org/cpython/rev/05dfed82457a

New changeset a609b2a44f92 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12250: test_socketserver uses a timeout of 60 seconds
http://hg.python.org/cpython/rev/a609b2a44f92

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12250>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:42:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 13:42:53 +0000
Subject: [issue12550] regrtest: register SIGALRM signal using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <1310650973.66.0.287757348069.issue12550@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I specified the wrong issue number if the commits:

New changeset d3cebbd500aa by Victor Stinner in branch '2.7':
Issue #12250: test_socketserver uses a timeout of 60 seconds instead of 20
http://hg.python.org/cpython/rev/d3cebbd500aa

New changeset 05dfed82457a by Victor Stinner in branch '3.2':
Issue #12250: test_socketserver uses a timeout of 60 seconds instead of 20
http://hg.python.org/cpython/rev/05dfed82457a

New changeset a609b2a44f92 by Victor Stinner in branch 'default':
(merge 3.2) Issue #12250: test_socketserver uses a timeout of 60 seconds
http://hg.python.org/cpython/rev/a609b2a44f92

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12550>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:43:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 13:43:04 +0000
Subject: [issue12250] regrtest: make --timeout explicit
In-Reply-To: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>
Message-ID: <1310650984.41.0.362753713384.issue12250@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg140332

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12250>
_______________________________________

From report at bugs.python.org  Thu Jul 14 15:43:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 13:43:58 +0000
Subject: [issue12250] regrtest: make --timeout explicit
In-Reply-To: <1307088132.85.0.485595882281.issue12250@psf.upfronthosting.co.za>
Message-ID: <1310651038.72.0.71578561961.issue12250@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(I commited fixes for issue #12550 but specified issue #12250 in the changlog, I removed the related comment from python-dev from this issue)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12250>
_______________________________________

From report at bugs.python.org  Thu Jul 14 16:02:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Jul 2011 14:02:44 +0000
Subject: [issue12550] regrtest: register SIGALRM signal using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <1310652164.78.0.240225255714.issue12550@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Can this be closed?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12550>
_______________________________________

From report at bugs.python.org  Thu Jul 14 16:15:43 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Jul 2011 14:15:43 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1310652943.07.0.629760724759.issue10403@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hello Eric, I missed noticing Alexander's comments in the reitveld, I looked only at tracker then. I see that some of them can be addressed. Like using members (components) of the field, instead of attributes when it is not an attribute. Shall correct it. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Thu Jul 14 16:27:13 2011
From: report at bugs.python.org (Arsouze)
Date: Thu, 14 Jul 2011 14:27:13 +0000
Subject: [issue12557] Crash idle on mac
In-Reply-To: <1310653633.65.0.219490792238.issue12557@psf.upfronthosting.co.za>
Message-ID: <1310653633.65.0.219490792238.issue12557@psf.upfronthosting.co.za>


New submission from Arsouze <georges.arsouze at gmail.com>:

Hi
Sorry for my poor english
I'am working on mac os snow leopard with Pyton 3.1
I want to use widgets Tix ot ttk
I have a error message : require Tile

Can you tell me step by step what i must do 
regards

----------
messages: 140337
nosy: georgesarsouze
priority: normal
severity: normal
status: open
title: Crash idle on mac
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12557>
_______________________________________

From report at bugs.python.org  Thu Jul 14 17:05:07 2011
From: report at bugs.python.org (Hans Bering)
Date: Thu, 14 Jul 2011 15:05:07 +0000
Subject: [issue12558] Locale-dependent crash for float width argument to
	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>


New submission from Hans Bering <hans.bering at arcor.de>:

The attached script will crash on a current Ubuntu with Python 3.2 + tcl/tk when using a locale which uses a comma as a decimal separator (e.g., German). It will not crash when using a locale which uses a dot as the decimal separator (e.g., English). In case of the crash, the output and stacktrace are as follows:

locale = ('de_DE', 'UTF8')
Traceback (most recent call last):
  File "tkinterCrash.py", line 20, in <module>
    tkcanvas = Canvas(master=master, width=w, height=2, borderwidth=4)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 2101, in __init__
    Widget.__init__(self, master, 'canvas', cnf, kw)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1961, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: bad screen distance "10.0"

Originally, we stumbled over this problem when using matplotlib, which passes/passed down float types as width arguments on occasions. It has been fixed there since (see https://github.com/matplotlib/matplotlib/pull/387).

The locale dependency can make this problem difficult to debug when it occurs. In our setup, we had a program work on one machine, but it crashed on the next machine, which we believed to have an identical setup; it took us a day to figure out what the difference was. We would expect the constructor to either always work with float arguments, or to always reject them, regardless of locale.

We have been able to reproduce this issue both with Python 2.7.2 and Python 3.2, both under a current Ubuntu and Windows 7.

----------
components: Tkinter
files: badScreenSizeTk.py
messages: 140338
nosy: hans.bering
priority: normal
severity: normal
status: open
title: Locale-dependent crash for float width argument to Tkinter widget constructor
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22653/badScreenSizeTk.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Thu Jul 14 17:07:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 15:07:33 +0000
Subject: [issue12557] Crash idle on mac
In-Reply-To: <1310653633.65.0.219490792238.issue12557@psf.upfronthosting.co.za>
Message-ID: <1310656053.48.0.592506472152.issue12557@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The tracker is a place to report bugs not get help.  (We don't have the manpower to provide help services here.)  Please try the python-list mailing list (gatewayed to comp.lang.python) or the python-tutor mailing list.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12557>
_______________________________________

From report at bugs.python.org  Thu Jul 14 17:08:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jul 2011 15:08:47 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1310656127.1.0.9914815.issue12556@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix, rosslagerwall
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Thu Jul 14 17:25:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 15:25:17 +0000
Subject: [issue12558] Locale-dependent crash for float width argument to
	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310657117.31.0.0876727336552.issue12558@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FYI 'crash' is for segfault.  A traceback is "just a bug" :)

I'm not sure that this it is worth having this as a separate bug from #10647, but I'll let someone with tk knowledge decide that.

----------
nosy: +kbk, r.david.murray, terry.reedy
superseder:  -> scrollbar crash in non-US locale format settings
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Thu Jul 14 17:26:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 15:26:20 +0000
Subject: [issue12558] Locale-dependent crash for float width argument to
	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310657180.96.0.292455856972.issue12558@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Thu Jul 14 17:26:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 15:26:32 +0000
Subject: [issue12558] Locale-dependent crash for float width argument to
	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310657192.84.0.193844521129.issue12558@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
superseder: scrollbar crash in non-US locale format settings -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Thu Jul 14 17:31:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Jul 2011 15:31:22 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

gzip.open() should parallel file.open() so that that zipped files can be read in the same way as regular files:

for line in gzip.open('notes.txt', 'r', encoding='latin-1'):
    print(line.rstrip())

----------
components: Library (Lib)
messages: 140341
nosy: rhettinger
priority: normal
severity: normal
status: open
title: gzip.open() needs an optional encoding argument
type: feature request
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________

From report at bugs.python.org  Thu Jul 14 18:15:43 2011
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 14 Jul 2011 16:15:43 +0000
Subject: [issue12558] Locale-dependent crash for float width argument to
	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310660143.61.0.355040513349.issue12558@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Why is this a bug ? You passed something that is not supposed to work with tk and tk said so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Thu Jul 14 18:58:12 2011
From: report at bugs.python.org (Stefan Sperling)
Date: Thu, 14 Jul 2011 16:58:12 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>


New submission from Stefan Sperling <stsp at apache.org>:

In Python-2.7.2 (I have not checked other versions, sorry),
the configure script doesn't not define LDLIBRARY on OpenBSD.
Because of this libpython.so does not get built.

----------
components: Build
files: python-2.7.2-configure.diff
keywords: patch
messages: 140343
nosy: stsp
priority: normal
severity: normal
status: open
title: libpython.so not built on OpenBSD
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file22654/python-2.7.2-configure.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Thu Jul 14 19:08:51 2011
From: report at bugs.python.org (Jim Schneider)
Date: Thu, 14 Jul 2011 17:08:51 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310663331.38.0.449204715669.issue5999@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Martin - <sys/_mbstate_t.h> provides a definition for mbstate_t only (at least on HP/UX 11i V2.0).  I can verify that the problem still exists for Python 3.2.1.  I am working on a workaround for this issue, and I will attach a patch once I get it to build.

----------
nosy: +jschneid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul 14 19:49:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jul 2011 17:49:17 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <E1QhQ2G-0001ww-7S@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 16bc59d37866 by Charles-Fran?ois Natali in branch '2.7':
Issue #12502: asyncore: fix polling loop with AF_UNIX sockets.
http://hg.python.org/cpython/rev/16bc59d37866

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Thu Jul 14 19:54:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jul 2011 17:54:08 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <E1QhQ6v-0002Oc-N6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 42ec507815d2 by Charles-Fran?ois Natali in branch '3.1':
Issue #12502: asyncore: fix polling loop with AF_UNIX sockets.
http://hg.python.org/cpython/rev/42ec507815d2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Thu Jul 14 19:57:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jul 2011 17:57:41 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <E1QhQAN-0002mo-Uv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ed90c1c8ee62 by Charles-Fran?ois Natali in branch '3.2':
Merge - Issue #12502: asyncore: fix polling loop with AF_UNIX sockets.
http://hg.python.org/cpython/rev/ed90c1c8ee62

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Thu Jul 14 19:59:41 2011
From: report at bugs.python.org (Jim Schneider)
Date: Thu, 14 Jul 2011 17:59:41 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>


New submission from Jim Schneider <jim.schneider at dataflux.com>:

In Modules/getpath.c, the following line (#138) causes problems with some compilers (HP/UX 11, in particular - there could be others):

static wchar_t *lib_python = L"lib/python" VERSION;

Similarly, line #644:

        module_search_path = L"" PYTHONPATH;

The default HP/UX compiler fails to compile this file with the error "Cannot concatenate character string literal and wide string literal".  The attached patch converts these two string literals to wide string literals that the HP/UX compiler can understand.

Very limited testing indicates that the patch is benign (it does not affect the build on Linux running on x86_64).

----------
components: Build
files: getpath.patch
keywords: patch
messages: 140348
nosy: jschneid
priority: normal
severity: normal
status: open
title: Compiler workaround for wide string constants in Modules/getpath.c (patch)
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file22655/getpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:00:03 2011
From: report at bugs.python.org (Piotr Zolnierczuk)
Date: Thu, 14 Jul 2011 18:00:03 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>


New submission from Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com>:

Hi,
I am trying to migrate from Python 2.5 to Python 2.7 I found though the mmap behaves differently on Windows XP between the two versions. It boils down to the following code:
import mmap
map1 = mmap.mmap(fileno=0, tagname='MyData', length=4096)
map2 = mmap.mmap(fileno=0, tagname='MyData', length=8192)

It runs fine (so I can "resize" shared memory) on XP with 2.5.4, but when running on 2.7.2 I get the following error

Traceback (most recent call last):
  File "D:\Workspace\memmap_test.py", line 3, in <module>
    map2 = mmap.mmap(fileno=0, tagname='MyData', length=8192)
WindowsError: [Error 5] Access is denied

----------
messages: 140349
nosy: zolnie
priority: normal
severity: normal
status: open
title: calling mmap twice fails on Windows
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12562>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:00:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jul 2011 18:00:39 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <E1QhQDG-00038k-9e@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ca077f2672e3 by Charles-Fran?ois Natali in branch 'default':
Merge - Issue #12502: asyncore: fix polling loop with AF_UNIX sockets.
http://hg.python.org/cpython/rev/ca077f2672e3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:00:42 2011
From: report at bugs.python.org (Piotr Zolnierczuk)
Date: Thu, 14 Jul 2011 18:00:42 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1310666442.04.0.47760345603.issue12562@psf.upfronthosting.co.za>


Changes by Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com>:


----------
components: +Windows
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12562>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:08:11 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Jul 2011 18:08:11 +0000
Subject: [issue12430] Pip fails to fetch from mirror if PyPi checksum times out
In-Reply-To: <1309262103.36.0.291566083366.issue12430@psf.upfronthosting.co.za>
Message-ID: <1310666891.35.0.118766448348.issue12430@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In any case, mirrors *do* mirror the checksums.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12430>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:18:29 2011
From: report at bugs.python.org (Jim Schneider)
Date: Thu, 14 Jul 2011 18:18:29 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310667509.84.0.346268126261.issue5999@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

I got it to build on HP-UX 11.  However, there are a lot of compiler warnings about type mismatches, the _ctypes, _multiprocessing and termios modules failed to build, and "make test" died after not finding a usable "binascii" module.

To get it to build, I did the following:
1)  Applied the patch I attached to issue 12561
2)  Created a directory sys, and copied /usr/include/sys/stdsyms.h into it.
3)  Did "chmod 644" on sys/stdsyms.h and applied the patch stdsyms.patch that I've attached to this issue to it.
4)  Ran configure with the argument "CPPFLAGS=-I."

At this point, make ran to completion, and produced a python binary.  However, "make test" dies within seconds of starting up.

----------
keywords: +patch
Added file: http://bugs.python.org/file22656/stdsyms.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:19:48 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Jul 2011 18:19:48 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310667588.85.0.170355636901.issue5999@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Jim, the question remains why it fails to compile then. If the type is defined, why does it give an error message "but has not been defined as a type"???

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:28:36 2011
From: report at bugs.python.org (Jim Schneider)
Date: Thu, 14 Jul 2011 18:28:36 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310668116.27.0.618965935356.issue5999@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Martin - sys/_mbstate.h is only included if _INCLUDE__STDC_A1_SOURCE is defined.  The only way this gets defined in the vendor-provided include files is if _XOPEN_SOURCE is defined and is equal to 500, or __STDC_VERSION__ is defined and is greater than or equal to 199901.

I've attached a patch to broaden the _XOPEN_SOURCE case (as the test should clearly have been >=, not ==).  Defining __STDC_VERSION__ to 199901 or greater will also do the job, but it feels more like a hack than just fixing what's broken in the vendor include files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:29:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Jul 2011 18:29:22 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310668162.37.0.350611613951.issue12561@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why is the __W macro needed?

Please don't call it WCHAR:
- it conflicts with a same-named macro on Windows
- you are applying it to strings, not characters

FWIW, the compiler doesn't conform to standard C if it rejects this code. 6.4.5p4 says

       [#4]   In  translation  phase  6,  the  multibyte  character
       sequences specified by any sequence  of  adjacent  character
       and  wide  string  literal  tokens  are  concatenated into a
       single multibyte character sequence.  If any of  the  tokens
       are  wide  string  literal  tokens,  the resulting multibyte
       character sequence is treated  as  a  wide  string  literal;
       otherwise, it is treated as a character string literal.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:35:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Jul 2011 18:35:05 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310668505.85.0.635460813842.issue5999@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That's a patch to HP-UX, right? Not one to Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:35:11 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:35:11 +0000
Subject: [issue12563] Check out my about.me profile!
In-Reply-To: <1310668507.7559571892889138@mf32.sendgrid.net>
Message-ID: <1310668507.7559571892889138@mf32.sendgrid.net>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1856_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1856_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=pALbODzFR4KGDIyxaHqpmw%2Fut

----------
files: unnamed
messages: 140357
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22657/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12563>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1856_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1856_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=pALbODzFR4KGDIyxaHqpmw%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=pALbODzFR4KGDIyxaHqpmw%2Foo0.gif" alt="">

From report at bugs.python.org  Thu Jul 14 20:36:11 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:36:11 +0000
Subject: [issue12564] Check out my about.me profile!
In-Reply-To: <1310668567.7988300458482942@mf38.sendgrid.net>
Message-ID: <1310668567.7988300458482942@mf38.sendgrid.net>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1857_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1857_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=TNIvc_YfTw6bmZBeA3uDMA%2Fut

----------
files: unnamed
messages: 140358
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22658/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12564>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1857_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1857_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=TNIvc_YfTw6bmZBeA3uDMA%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=TNIvc_YfTw6bmZBeA3uDMA%2Foo0.gif" alt="">

From report at bugs.python.org  Thu Jul 14 20:36:47 2011
From: report at bugs.python.org (Jim Schneider)
Date: Thu, 14 Jul 2011 18:36:47 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310668607.96.0.99144317007.issue12561@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

The __W macro is needed because the token-pasting operator binds to the macro's argument immediately;  Having WCHAR(y) expand to __W(y) means that __W is passed WCHAR's argument after it's been macro-expanded.  Without the intermediate step, WCHAR(VERSION) becomes LVERSION.

As for the name - I have no objection to reasonable name changes.  I picked WCHAR because it converts its argument to a wchar_t *.

Finally - I am aware that the HP/UX C compiler is broken.  Unfortunately, I am required to work with it, and can neither replace it nor ignore it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:37:11 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:37:11 +0000
Subject: [issue12565] Check out my about.me profile!
In-Reply-To: <1310668628.2834231238001778@mf8.sendgrid.net>
Message-ID: <1310668628.2834231238001778@mf8.sendgrid.net>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1858_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1858_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=sKR-vgz5SBKaB5LfWMBuDg%2Fut

----------
files: unnamed
messages: 140360
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22659/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12565>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1858_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1858_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=sKR-vgz5SBKaB5LfWMBuDg%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=sKR-vgz5SBKaB5LfWMBuDg%2Foo0.gif" alt="">

From report at bugs.python.org  Thu Jul 14 20:37:47 2011
From: report at bugs.python.org (Jim Schneider)
Date: Thu, 14 Jul 2011 18:37:47 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310668667.18.0.693086844569.issue5999@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Yes, it is a patch to an HP-provided C compiler system header file.  I cannot provide the actual file it patches, due to copyright limitations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:38:13 2011
From: report at bugs.python.org (gungor)
Date: Thu, 14 Jul 2011 18:38:13 +0000
Subject: [issue12566] Check out my about.me profile!
In-Reply-To: <1310668688.5031802608087416@mf19>
Message-ID: <1310668688.5031802608087416@mf19>


New submission from gungor <gungorbasa at gmail.com>:

Hi Python,

I set up my about.me splash page and want to share it with you: <http://about.me/gungorbasa?promo=share_1859_378462>.

If you don't have an about.me splash page, you can get one for free at <http://about.me?promo=share_1859_378462>. Names are going fast so you might want to get yours now.

G??ng??rIf you would like to unsubscribe and stop receiving these emails click here: http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&u=O-EGT9YnTHaZ2hKIsi8xlw%2Fut

----------
files: unnamed
messages: 140362
nosy: gungorbasa
priority: normal
severity: normal
status: open
title: Check out my about.me profile!
Added file: http://bugs.python.org/file22660/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12566>
_______________________________________
-------------- next part --------------
Hi Python,<br><br>I set up my about.me splash page and want to share it with you: <a href="http://about.me/gungorbasa?promo=share_1859_378462">http://about.me/gungorbasa</a>.<br><br>If you don't have an about.me splash page, you can get one for free at <a href="http://about.me?promo=share_1859_378462">http://about.me</a>. Names are going fast so you might want to get yours now.<br><br>G??ng??r<p>
	If you would like to unsubscribe and stop receiving these emails <a href="http://email.about.me/wf/unsubscribe?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=O-EGT9YnTHaZ2hKIsi8xlw%2Fuh">click here</a>.</p>

<img src="http://email.about.me/wf/open?rp=Er%2BBdZSP6nTkZci6SREkGqX5gSZJ4%2F0QZJ4Ffae3DStZkB4kgwyA2ibIRCSN5vDKSXYX2zIEziWyMTT%2Faa5x7A%3D%3D&amp;u=O-EGT9YnTHaZ2hKIsi8xlw%2Foo0.gif" alt="">

From report at bugs.python.org  Thu Jul 14 20:40:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 18:40:53 +0000
Subject: [issue12563] Check out my about.me profile!
In-Reply-To: <1310668507.7559571892889138@mf32.sendgrid.net>
Message-ID: <1310668853.03.0.690679364963.issue12563@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

spam

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12563>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:41:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 18:41:15 +0000
Subject: [issue12566] Check out my about.me profile!
In-Reply-To: <1310668688.5031802608087416@mf19>
Message-ID: <1310668875.14.0.313231717313.issue12566@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

spam

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12566>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:41:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 18:41:31 +0000
Subject: [issue12565] Check out my about.me profile!
In-Reply-To: <1310668628.2834231238001778@mf8.sendgrid.net>
Message-ID: <1310668891.94.0.917211688507.issue12565@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

spam

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12565>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:41:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jul 2011 18:41:56 +0000
Subject: [issue12564] Check out my about.me profile!
In-Reply-To: <1310668567.7988300458482942@mf38.sendgrid.net>
Message-ID: <1310668916.1.0.877928826907.issue12564@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

spam

----------
nosy: +r.david.murray
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12564>
_______________________________________

From report at bugs.python.org  Thu Jul 14 20:55:24 2011
From: report at bugs.python.org (Hans Bering)
Date: Thu, 14 Jul 2011 18:55:24 +0000
Subject: [issue12558] Locale-dependent crash for float width argument to
	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310669724.03.0.800451907266.issue12558@psf.upfronthosting.co.za>


Hans Bering <hans.bering at arcor.de> added the comment:

Sorry for the misclassification, and thanks for correcting that.

I agree, this issue is most likely related to issue 10647; but at some level I think they must be different, because issue 10647 seems to be specific to Python 3.1 under Windows; I could not reproduce that issue neither under Ubuntu nor with Python 3.2 in Windows. This behaviour on the other hand I could reproduce with Python 2.7 and Python 3.2 in both Ubuntu and Windows. The underlying problem in both cases, I believe, is similar: That int/float arguments are somewhere turned into locale-dependent string representations and later parsed back using a potentially different locale.

Which brings me to why I consider this to be a bug - sorry for not having made that point clearer: The handling of the float argument depends on the system locale. If you change the example script to run with an English locale, you do not get an error; instead, the float is implicitly used as an int, and everything is fine. Only if you use German or a similar locale, will the float trigger an error. So the behaviour is at the very least inconsistent. If treating a float argument as an error is deemed acceptable, then this error should not be locale-dependent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Thu Jul 14 21:05:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 19:05:44 +0000
Subject: [issue12550] regrtest: register SIGALRM signal using faulthandler
In-Reply-To: <1310552052.01.0.62401562822.issue12550@psf.upfronthosting.co.za>
Message-ID: <1310670344.05.0.376135084103.issue12550@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Can this be closed?

I think (hope) that the initial issue (test_socketserver) failure is fixed, thanks to my second commit.

I'm not complelty satisfied because the traceback was not printed on a SIGALRM when i tried -m test -F test_socketserver. But if I raise manually the signal, using signal.alarm(10) for example, the traceback was printed on FreeBSD 6.4 and let close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12550>
_______________________________________

From report at bugs.python.org  Thu Jul 14 21:23:11 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 14 Jul 2011 19:23:11 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1310671391.16.0.956031785031.issue12559@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Here is a patch. If the code changes are acceptable I can also make a documentation patch.

(I'm surprised to see 3.2 in "Versions". I thought 3.2 only gets bugfixes...)

----------
keywords: +patch
nosy: +durban
Added file: http://bugs.python.org/file22661/issue12559.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________

From report at bugs.python.org  Thu Jul 14 21:40:04 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 14 Jul 2011 19:40:04 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310672404.02.0.610075698821.issue12555@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 14 21:48:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Jul 2011 19:48:30 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1310672910.34.0.681753290846.issue10647@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg139566

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Thu Jul 14 21:48:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Jul 2011 19:48:40 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1310672920.23.0.994815301859.issue10647@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg139876

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Thu Jul 14 21:49:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Jul 2011 19:49:18 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1310672958.01.0.782910087059.issue10647@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Two messages deleted at Hans' request since he opened #12558
Hans says there that he could not reproduce *this* issue with 3.2.
Herm, please retry with 3.2 as 3.1.4 is last bugfix for 3.1 series.
If this works on 3.2, this should be closed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Thu Jul 14 22:10:31 2011
From: report at bugs.python.org (Nicholas Cole)
Date: Thu, 14 Jul 2011 20:10:31 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310674231.57.0.679487390588.issue6755@psf.upfronthosting.co.za>


Nicholas Cole <nicholas.cole at gmail.com> added the comment:

The bug is marked "Test Needed".

I am very keen to see this issue fixed, and would be very willing to help, but I don't really know what is still required. As far as I can see there is a patch waiting - what is the hold up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Thu Jul 14 22:22:00 2011
From: report at bugs.python.org (Herm Fischer)
Date: Thu, 14 Jul 2011 20:22:00 +0000
Subject: [issue10647] scrollbar crash in non-US locale format settings
In-Reply-To: <1291755334.73.0.599361686975.issue10647@psf.upfronthosting.co.za>
Message-ID: <1310674920.7.0.650139447651.issue10647@psf.upfronthosting.co.za>


Herm Fischer <fischer at markv.com> added the comment:

Yes, I can confirmm that this issue is gone on 3.2.  Closed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10647>
_______________________________________

From report at bugs.python.org  Thu Jul 14 22:44:14 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 14 Jul 2011 20:44:14 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1310676254.83.0.816506062922.issue12559@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

There remains a difference between open() and gzip.open():
open(filename, 'r', encoding=None) is a text file (with a default encoding), gzip.open() with the same arguments returns a binary file.

Don't know how to fix this though.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________

From report at bugs.python.org  Thu Jul 14 23:08:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Jul 2011 21:08:42 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <E1QhT9F-00033p-Fr@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dec10ad41b2a by Victor Stinner in branch 'default':
Close #6755: Add get_wch() method to curses.window class
http://hg.python.org/cpython/rev/dec10ad41b2a

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 00:05:28 2011
From: report at bugs.python.org (John Doe)
Date: Thu, 14 Jul 2011 22:05:28 +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: <1310681128.37.0.816917566548.issue8728@psf.upfronthosting.co.za>


Changes by John Doe <gainmax512 at gmail.com>:


----------
nosy: +John.Doe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8728>
_______________________________________

From report at bugs.python.org  Fri Jul 15 00:30:31 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Jul 2011 22:30:31 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310682631.41.0.878560877404.issue12555@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/issue12555>
_______________________________________

From report at bugs.python.org  Fri Jul 15 00:33:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 22:33:37 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

curses functions accepting strings encode implicitly character strings to UTF-8. This is wrong. We should add a function to set the encoding (see issue #6745) or use the wide character C functions. I don't think that UTF-8 is the right default encoding, I suppose that the locale encoding is a better choice.

Accepting characters (and character strings) but calling byte functions is wrong. For example, addch('?') doesn't work with UTF-8 locale encoding. It calls waddch(0xE9) (? is U+00E9), whereas waddch(0xC3)+waddch(0xA9) should be called. Workaround in Python:

    for byte in '?'.encode('utf-8'):
        win.addch(byte)

I see two possible solutions:

A) Add a new functions only accepting characters, and not accept characters in the existing functions

B) The function should be fixed to call the right C function depending on the input type. For example, Python addch(10) and addch(b'\n') would call waddch(10), whereas addch('?') would call wadd_wch(233).

I prefer solution (B) because addch('?') would just work as expected.

----------
components: Library (Lib)
messages: 140375
nosy: Nicholas.Cole, akuchling, cben, gpolo, haypo, inigoserna, python-dev, r.david.murray, schodet, zeha
priority: normal
severity: normal
status: open
title: curses implementation of Unicode is wrong in Python 3
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Jul 15 00:43:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 22:43:56 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Some characters take more than one column in a terminal, especially CJK (chinese, japanese, korean) characters. If you use such character in a terminal without taking care of the width in columns of each character, the text alignment can be broken. Issue #2382 is an example of this problem.

#2382 and #6755 have patches implementing such function:
- unicode_width.patch of #2382 adds unicode.width() method
- ucs2w.c of #6755 creates a new ucs2w module with two functions: unichr2w() (width of a character) and ucs2w() (width of a string)

Use test_ucs2w.py of #6755 to test these new functions/methods.

----------
components: Unicode
messages: 140376
nosy: haypo, inigoserna
priority: normal
severity: normal
status: open
title: Add functions to get the width in columns of a character
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Fri Jul 15 00:44:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 22:44:31 +0000
Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character
	is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1310683471.4.0.113610518949.issue2382@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I just created the issue #12568 for unicode_width.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2382>
_______________________________________

From report at bugs.python.org  Fri Jul 15 00:45:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 22:45:56 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310683556.65.0.132149602078.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I don't really know what is still required

_cursesmodule.311.get_wch.patch doesn't apply correctly on Python 3.3 and use PyInt_FromLong() function, function removed from Python 3.0. Indeed, I?igo wrote that the patch was not tested.

> what is the hold up?

Nobody wanted to take the responsability of the choice for get_wch(): add a new method or patch getch() ;-)

--

I commited I?igo's patch to add window.get_wch() method with minor changes:

 - add :versionadded: 3.3 in the doc
 - document the new method What's new in Python 3.3 document
 - fix an error message: getch => get_wch
 - change error message (if ch==ERROR): "get_wch failed" => "no input" (message copied from the getch function)

--

I think that the Unicode support of curses in Python 3 is just completly broken: I opened a new issue for that, issue #12567.

I also create the issue #12568 to add a function to get the width of a character.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 01:09:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 23:09:34 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1310684974.36.0.637442375404.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

getkey.patch fixes window.getkey(): use get_wch() instead of getch() to handle correctly non-ASCII characters. I tested with the key ? (U+00E9) with ISO-8859-1 and UTF-8 locale encoding: getkey() gives the expected result (but addstr is unable to display it, because addstr encodes the string to UTF-8 instead of the locale encoding).

----------
keywords: +patch
Added file: http://bugs.python.org/file22662/getkey.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Jul 15 01:10:42 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Jul 2011 23:10:42 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1310685042.05.0.626820108092.issue12560@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
assignee:  -> skrah
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Fri Jul 15 01:21:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Jul 2011 23:21:52 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1310685712.05.0.541097103945.issue6745@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created issue #12567 to fix the Unicode support of the curses module in Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Fri Jul 15 01:23:42 2011
From: report at bugs.python.org (Jeremy Banks)
Date: Thu, 14 Jul 2011 23:23:42 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>


New submission from Jeremy Banks <jeremy at jeremybanks.ca>:

I was experimenting with the sqlite3 library and noticed that using certain strings as identifiers cause bus errors or segfaults. I'm not very familiar with unicode, but after some Googling I'm pretty sure this happens when I use non-characters or surrogate characters incorrectly.

This causes a bus error:

import sqlite3
c = sqlite3.connect(":memory:")
table_name = '"' + chr(0xD800) + '"'
c.execute("create table " + table_name + " (bar)")

The equivalent Python 2 (replacing chr with unichr) works properly.

----------
components: Library (Lib)
messages: 140381
nosy: jeremybanks
priority: normal
severity: normal
status: open
title: sqlite3 segfaults and bus errors when given certain unicode strings as queries
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 01:33:00 2011
From: report at bugs.python.org (Alexander Slesarev)
Date: Thu, 14 Jul 2011 23:33:00 +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: <1310686380.43.0.531058651039.issue9878@psf.upfronthosting.co.za>


Changes by Alexander Slesarev <alex.slesarev at gmail.com>:


----------
nosy: +nuald

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Fri Jul 15 01:49:05 2011
From: report at bugs.python.org (Philip Horger)
Date: Thu, 14 Jul 2011 23:49:05 +0000
Subject: [issue12570] BaseHTTPServer.shutdown() locks if the last request 404'd
In-Reply-To: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>
Message-ID: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>


New submission from Philip Horger <campadrenalin at gmail.com>:

I haven't yet checked to see if other errors mess it up, but it refuses to exit the serve_forever() loop if the last request had a 404 error.

----------
components: Library (Lib)
messages: 140382
nosy: Philip.Horger
priority: normal
severity: normal
status: open
title: BaseHTTPServer.shutdown() locks if the last request 404'd
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12570>
_______________________________________

From report at bugs.python.org  Fri Jul 15 01:52:58 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Jul 2011 23:52:58 +0000
Subject: [issue12570] BaseHTTPServer.shutdown() locks if the last request 404'd
In-Reply-To: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>
Message-ID: <1310687578.7.0.816069802518.issue12570@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Can you please provide an example snippet with your expectation of the behavior?

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12570>
_______________________________________

From report at bugs.python.org  Fri Jul 15 02:37:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Jul 2011 00:37:03 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1310690223.05.0.773483726164.issue12559@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________

From report at bugs.python.org  Fri Jul 15 05:24:10 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Jul 2011 03:24:10 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310700250.36.0.104080436214.issue12569@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

What operating system platform and version are you seeing this behavior? Also can you report the versions of sqlite3 adapter and the sqlite3 library by executing the following in the interpreter?

>>> sqlite3.version
'2.6.0'
>>> sqlite3.sqlite_version
'3.6.12'

On Linux and OS X systems I've tested, rather than a segfault your test case causes an exception to be raised.

For Python 3.1.4:
"sqlite3.Warning: SQL is of wrong type. Must be string or unicode."

For Python 3.2.1
"UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 14: surrogates not allowed"

----------
nosy: +ghaering, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 05:43:06 2011
From: report at bugs.python.org (Jeremy Banks)
Date: Fri, 15 Jul 2011 03:43:06 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310701386.84.0.538876832656.issue12569@psf.upfronthosting.co.za>


Jeremy Banks <jeremy at jeremybanks.ca> added the comment:

I'm using OS X 10.6.7.

The bus error is occurring with my Python 3.1 installation:
  path: /Library/Frameworks/Python.framework/Versions/3.1/bin/python3
  sqlite3.version == 2.4.1
  sqlite3.sqlite_version = 3.6.11.

But now that you mention it, my MacPorts installations of Python 3.0 and 3.1 just get an exception like you do:
  paths: /opt/local/bin/python3.0 / python3.1
  sqlite3.version == 2.4.1
  sqlite3.sqlite_version == 3.7.7.1

A Python 2.7 installation where it works without any error:
  path: /Library/Frameworks/Python.framework/Versions/2.7/bin/python
  sqlite3.version == 2.6.0
  sqlite3.sqlite_version == 3.6.12

A MacPorts Python 2.6 installation where it works without any error:
  path: /opt/local/bin/python2.6
  sqlite3.version == 2.4.1
  sqlite3.sqlite_version == 3.7.7.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 06:21:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 15 Jul 2011 04:21:16 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1310703676.86.0.36317713085.issue12567@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/issue12567>
_______________________________________

From report at bugs.python.org  Fri Jul 15 06:36:06 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Jul 2011 04:36:06 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310704566.74.0.14587838416.issue12569@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Sorry, I cannot reproduce on Mac OS X 10.6.8 the crash behavior you report using various Python 3.1.x installed from the python.org Python OS X installers, in particular, 3.1 and 3.1.4 (the first and the most recent 3.1 releases).  If this Python instance was not installed from a python.org installer, I suggest contacting the distributor that supplied it.  If you built it from source, suggest checking what ./configure options you used and which copy of the sqlite3 library was used.  You might want to take this opportunity to update to Python 3.2.1 since no further bug fixes (other than security fixes) are expected to be released for 3.1.x.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 06:40:20 2011
From: report at bugs.python.org (Jeremy Banks)
Date: Fri, 15 Jul 2011 04:40:20 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310704820.62.0.209320306699.issue12569@psf.upfronthosting.co.za>


Jeremy Banks <jeremy at jeremybanks.ca> added the comment:

I'll try that, thank you.

If it works without exception in Python 2, isn't the behaviour in Python 3 a regression bug, even if it doesn't crash? If so, should I create a new/separate issue for the behaviour?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 08:13:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 15 Jul 2011 06:13:46 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1310710426.16.0.344242229082.issue12502@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed, closing.
Alexey, thanks for reporting this.
(I'll open a separate issue to increase the tests coverage).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Fri Jul 15 08:47:44 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Jul 2011 06:47:44 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310712464.52.0.705966131833.issue12569@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

0xD800 does not represent a valid Unicode character; it's a surrogate code point (see http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Surrogates).  If you use a code point that does represent a Unicode character, say 0xA800, there is no error.  If there is a bug here, it's that the Python 2 version does not report an error for this edge case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:14:38 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 15 Jul 2011 07:14:38 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1310714078.86.0.220212814495.issue12502@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
versions: +Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:14:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 15 Jul 2011 07:14:44 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1310714084.77.0.472472139297.issue12502@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:30:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 07:30:12 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1310715012.64.0.226907031502.issue12502@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg140388

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:30:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 07:30:56 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1310715056.21.0.94298803876.issue12502@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Woops, I don't know how, but I removed a neologix's message:

"Patch committed, closing.
Alexey, thanks for reporting this.
(I'll open a separate issue to increase the tests coverage)."

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12502>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:36:10 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 15 Jul 2011 07:36:10 +0000
Subject: [issue12571] Python built on Linux 3.0 doesn't include DLFCN
In-Reply-To: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>
Message-ID: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

This seems similar to issue 12326, but it doesn't seem similar enough to include it there: the DLFCN module seems to not be built when running against a 3.0 kernel. See https://bugs.gentoo.org/show_bug.cgi?id=374579.

----------
messages: 140391
nosy: djc
priority: normal
severity: normal
status: open
title: Python built on Linux 3.0 doesn't include DLFCN

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12571>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:36:15 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 15 Jul 2011 07:36:15 +0000
Subject: [issue12571] Python built on Linux 3.0 doesn't include DLFCN
In-Reply-To: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>
Message-ID: <1310715375.23.0.225934843631.issue12571@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12571>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:41:42 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 15 Jul 2011 07:41:42 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1310715702.62.0.453365446934.issue12326@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:47:17 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 15 Jul 2011 07:47:17 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1310716037.56.0.390041939314.issue12555@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Fri Jul 15 09:50:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 07:50:54 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310716254.45.0.647229499942.issue12569@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I already fixed this issue in Python 3.1, 3.2 and 3.3: issue #6697 (e.g. commit 7ba851d1b46e).

$ ./python 
Python 3.3.0a0 (default:ab162f925761, Jul 15 2011, 09:36:17) 
>>> import sqlite3
>>> c = sqlite3.connect(":memory:")
>>> table_name = '"' + chr(0xD800) + '"'
>>> c.execute("create table " + table_name + " (bar)")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 14: surrogates not allowed

@jeremybanks: I don't think that you use sqlite3 coming from Python 3 but the third party module.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 10:02:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 08:02:17 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310716937.38.0.0160250522365.issue12569@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I already fixed this issue in Python 3.1, 3.2 and 3.3:
> issue #6697 (e.g. commit 7ba851d1b46e).

Oh, wrong: the bug was only fixed in Python 3.2 and 3.3. There was already a check after _PyUnicode_AsStringAndSize(), but the test was on the wrong variable (operation vs operation_cstr).

Because only security bugs can be fixed in Python 3.1, I think that this issue should be closed. Or do you consider dereferencing a NULL pointer in sqlite3 as a security vulnerability?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 10:06:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 15 Jul 2011 08:06:20 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1310717180.0.0.432500090681.issue12326@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here we go, first Linux3-related bug report:
https://bugs.gentoo.org/show_bug.cgi?id=374579 (see issue #12571).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jul 15 10:30:51 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Jul 2011 08:30:51 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310718651.23.0.390736839801.issue12569@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It seems that a fix was merged in the 3.1 branch, somewhere between 3.1.2 and 3.1.3.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 10:32:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 08:32:06 +0000
Subject: [issue12571] Python built on Linux 3.0 doesn't include DLFCN
In-Reply-To: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>
Message-ID: <1310718726.02.0.872993400751.issue12571@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is related to issue #12326.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12571>
_______________________________________

From report at bugs.python.org  Fri Jul 15 10:36:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 08:36:50 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1310719010.29.0.524397451586.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here we go, first Linux3-related bug report:
> https://bugs.gentoo.org/show_bug.cgi?id=374579 (see issue #12571).

Oh, some people use the DLFCN module :-)

--

I'm still in favor of keeping sys.platform == 'linux3', and you?

For plat-linux3, should we regenerate this directory (I cannot do that, I don't have Linux 3.0 yet) or can we just use a symbolic link? I read that Linux 3.0 doesn't break the API, so I suppose that constants are the same. Or can we try by copying plat-linux2 to plat-linux3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jul 15 10:40:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 08:40:36 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310719236.31.0.910297585647.issue12569@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It seems that a fix was merged in the 3.1 branch,
> somewhere between 3.1.2 and 3.1.3.

Which fix? The code is still wrong in Mercurial (branch 3.1):

   493     operation_cstr = _PyUnicode_AsStringAndSize(operation, &operation_len);
   494     if (operation == NULL)
   495         goto error;

http://hg.python.org/cpython/file/42ec507815d2/Modules/_sqlite/cursor.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 11:14:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 09:14:54 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1310721294.78.0.0649868904799.issue1813@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The decimal module has been fixed in Python 2.7, 3.2 and 3.3 for Turkish local: issue #11830.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Fri Jul 15 11:56:42 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Jul 2011 09:56:42 +0000
Subject: [issue12569] sqlite3 segfaults and bus errors when given certain
	unicode strings as queries
In-Reply-To: <1310685822.64.0.0540241463817.issue12569@psf.upfronthosting.co.za>
Message-ID: <1310723802.49.0.832743357093.issue12569@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The fix was c073f3c3276e (thanks to hg bisect)
the variable operation_cstr is not used before the call to pysqlite_cache_get(), which also tries to encode the statement into utf8 and correctly raises an exception.
In early 3.1.2, the segfault came from the DECREF of an uninitialized member...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12569>
_______________________________________

From report at bugs.python.org  Fri Jul 15 12:58:36 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 15 Jul 2011 10:58:36 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310727516.58.0.315041304614.issue12544@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I wouldn't object to having a cyclic reference test for TestCase, although if it ever becomes a problem for the development of unittest we may have to disable it again. I think Benjamin said he would like to modify the test from Martin's patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Fri Jul 15 13:17:45 2011
From: report at bugs.python.org (Nir Aides)
Date: Fri, 15 Jul 2011 11:17:45 +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: <1310728665.07.0.090197080132.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Here is a morning reasoning exercise - please help find the flaws or refine it:


5) Sanitizing worker threads in the multiprocessing module

Sanitizing a worker thread in the context of this problem is to make sure it can not create a state that may deadlock another thread that calls fork(); or in other words fork-safe.
Keep in mind that in Python os.fork() is never called from a POSIX signal handler.
So what are examples of a fork-safe thread?

a) A thread that spins endlessly doing nothing in a C for(;;) loop is safe.

Another thread may call fork() without restrictions.

b) A Python thread that only calls function that do not yield the GIL and that does not acquire locks that are held beyond a Python tick is safe.

An example for such a lock is a critical-section lock acquired by a lower level third party library for the duration of a function call.
Such a lock will be released by the time os.fork() is called because of the GIL.

c) A Python thread that in addition to (2) also acquires a lock that is handled at fork is safe.

d) A Python thread that in addition to (2) and (3) calls function that yield the GIL but while the GIL is released only calls async-signal-safe code.

This is a bit tricky. We know that it is safe for thread A to fork and call async-signal-safe functions regardless of what thread B has been doing, but I do not know that thread A can fork and call non async-signal-safe functions if thread B was only calling async-signal-safe functions.

Nevertheless it makes sense: For example lets assume it isn't true, and that hypothetical thread A forked while thread B was doing the async-signal-safe function safe_foo(), and then thread A called non async-signal-safe function unsafe_bar() and deadlocked.

unsafe_bar() could have deadlocked trying to acquire a lock that was acquired by safe_foo(). But if this is so, then it could also happen the other way around.
Are there other practical possibilities?

Either way, we could double check and white list the async-signal-safe functions we are interested in, in a particular implementation.

e) Socket related functions such as bind() accept() send() and recv(), that Python calls without holding the GIL, are all async-signal-safe.

This means that in principle we can have a fork-safe worker thread for the purpose of communicating with a forked process using a socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:17:09 2011
From: report at bugs.python.org (Nicholas Cole)
Date: Fri, 15 Jul 2011 13:17:09 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1310735829.59.0.227844424586.issue12568@psf.upfronthosting.co.za>


Changes by Nicholas Cole <nicholas.cole at gmail.com>:


----------
nosy: +Nicholas.Cole

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:21:57 2011
From: report at bugs.python.org (Nicholas Cole)
Date: Fri, 15 Jul 2011 13:21:57 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310736117.55.0.995149398221.issue6755@psf.upfronthosting.co.za>


Nicholas Cole <nicholas.cole at gmail.com> added the comment:

> Nobody wanted to take the responsability of the choice for get_wch(): add a new method or patch getch() ;-)

I suspect that a new method is the right way to go, here.  

I see it has been moved to "committed/rejected" status - does that mean that it might still go in, or that it is rejected?

> I think that the Unicode support of curses in Python 3 is just completly broken

It certainly is less than ideal. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:28:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 13:28:50 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310736530.85.0.868233374237.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I see it has been moved to "committed/rejected"
> status - does that mean that it might still go in, or that
> it is rejected?

I commited the new method, did you see my commit dec10ad41b2a?

I propose to continue the discussion on issue #12567 (for example, to decide if we need unget_wch or not).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:31:26 2011
From: report at bugs.python.org (Christian Hofstaedtler)
Date: Fri, 15 Jul 2011 13:31:26 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1310736686.01.0.801523612194.issue12568@psf.upfronthosting.co.za>


Changes by Christian Hofstaedtler <ch+pythonbugs at zeha.at>:


----------
nosy: +zeha

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:33:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 13:33:55 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1310736835.75.0.258797458968.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, by the way: do all platforms have wide character functions? I don't see any failure on our Python 3.x buildbots, but test_curses is skipped on many buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:56:48 2011
From: report at bugs.python.org (Nicholas Cole)
Date: Fri, 15 Jul 2011 13:56:48 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1310738208.03.0.848974432742.issue12567@psf.upfronthosting.co.za>


Nicholas Cole <nicholas.cole at gmail.com> added the comment:

I think that some platforms do not have wide character support, though I could be wrong.  The FAQ here: http://invisible-island.net/ncurses/ncurses.faq.html  has a list of those that do and those that don't, but I don't know how up to date it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:57:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 13:57:15 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1310738235.69.0.673506813734.issue12559@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If we go this way, the "errors" and "newline" argument should be added as well.

----------
nosy: +pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________

From report at bugs.python.org  Fri Jul 15 15:58:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 13:58:33 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310738313.13.0.198297058798.issue6755@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

/home/antoine/cpython/default/Modules/_cursesmodule.c: In function ?PyCursesWindow_Get_WCh?:
/home/antoine/cpython/default/Modules/_cursesmodule.c:919:9: attention : implicit declaration of function ?wget_wch?
/home/antoine/cpython/default/Modules/_cursesmodule.c:926:9: attention : implicit declaration of function ?mvwget_wch?
gcc -pthread -shared build/temp.linux-x86_64-3.3-pydebug/home/antoine/cpython/default/Modules/_cursesmodule.o -L/usr/local/lib -lncurses -o build/lib.linux-x86_64-3.3-pydebug/_curses.cpython-33dm.so
*** WARNING: renaming "_curses" since importing it failed: build/lib.linux-x86_64-3.3-pydebug/_curses.cpython-33dm.so: undefined symbol: mvwget_wch
*** WARNING: importing extension "_curses_panel" failed with <class 'SystemError'>: initialization of _curses_panel raised unreported exception

Failed to build these modules:
_curses            _curses_panel

----------
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 16:15:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 14:15:01 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310739301.74.0.942353150646.issue6755@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also compilation warnings on some buildbots:

/var/lib/buildslave/3.x.murray-gentoo-wide/build/Modules/_cursesmodule.c: In function 'PyCursesWindow_Get_WCh':
/var/lib/buildslave/3.x.murray-gentoo-wide/build/Modules/_cursesmodule.c:919: warning: implicit declaration of function 'wget_wch'
/var/lib/buildslave/3.x.murray-gentoo-wide/build/Modules/_cursesmodule.c:926: warning: implicit declaration of function 'mvwget_wch'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 16:36:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 14:36:35 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310740595.77.0.596911692882.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> implicit declaration of function ?wget_wch?

Oh oh, I expected such error: it means that your ncurses library don't have the wide character API. The compiler command confirm that: "gcc ... -lncurses ...". You use libncurses and not libncursesw.

Antoine told me that libncursesw is available on its OS, but Python chose libncurses. I suppose that it's because readline is linked to libncurses (and not libncursesw) => see issue #7384.

Antoine setup is not rare: many Linux distro link readline to libncurses, and so Python cannot use libncursesw.

For this issue, it's not a problem: we can just add a test to check if get_wch is available or not, and only define the Python function if the C function does exist. But for #12567, it's a bigger problem because it means that we cannot always use the wide character functions if the argument is Unicode (character/string).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 16:39:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 14:39:09 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1310740749.89.0.812883768864.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> by the way: do all platforms have wide character functions?

See msg140408 and msg140409: Antoine Pitrou (OS=Mageia 1) and some buildbots don't have get_wch().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Fri Jul 15 16:43:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 14:43:16 +0000
Subject: [issue2506] Add mechanism to disable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1310740996.94.0.860787941655.issue2506@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Add mechanism to diasable optimizations -> Add mechanism to disable optimizations

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Fri Jul 15 16:43:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 14:43:41 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1310741021.07.0.261585339088.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ... I suppose that it's because readline is linked to libncurses
> (and not libncursesw) => see issue #7384.

See also the issue #9408.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 15 16:50:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Jul 2011 14:50:35 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310727516.58.0.315041304614.issue12544@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o81=t+o5OCEbquzUqrnZ1HLh2feNG4mtxzQvwZAQ-LZow@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Done.

2011/7/15 Michael Foord <report at bugs.python.org>:
>
> Michael Foord <michael at voidspace.org.uk> added the comment:
>
> I wouldn't object to having a cyclic reference test for TestCase, although if it ever becomes a problem for the development of unittest we may have to disable it again. I think Benjamin said he would like to modify the test from Martin's patch.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12544>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:03:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:03:01 +0000
Subject: [issue12544] Avoid using a pseudo-dict for _type_equality_funcs in
	unittest
In-Reply-To: <1310515554.23.0.512322223781.issue12544@psf.upfronthosting.co.za>
Message-ID: <1310742181.66.0.0793711500597.issue12544@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, some assertions about GC are embedded in the tests, for example test_set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12544>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:13:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:13:44 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310742824.94.0.476519233793.issue3177@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> as long as it's implemented and it's in the standard library, and
> people don't have to use subprocess to run open or xdg-open themselves
> as I currently do.

This new function would call os.startfile on Windows, xdg-open where applicable, and open on Mac OS X (using a subprocess for these last two).

I found the python-ideas thread: http://mail.python.org/pipermail/python-ideas/2011-July/010674.html
There was only limited support.

----------
dependencies: +Finding programs in PATH, adding shutil.which
title: implement os.startfile on posix and MacOSX -> Add shutil.open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:15:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 15:15:06 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1310742906.8.0.539311387327.issue444582@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/issue444582>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:19:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 15:19:26 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310743166.96.0.417847731381.issue3177@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> dependencies: + Finding programs in PATH, adding shutil.which

Why did you add this dependency? For example, subprocess is able to locate a program if the program has no full path. We don't need a which function.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:20:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:20:12 +0000
Subject: [issue1301512] desktop module (providing startfile as open,
	all platforms)
Message-ID: <1310743212.47.0.627856236105.issue1301512@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was proposed anew as #3177.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1301512>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:20:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:20:41 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310743241.64.0.0854944311784.issue3177@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also lengthy discussion on #1301512.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:25:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:25:48 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1310743548.64.0.723898174116.issue3177@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> dependencies: + Finding programs in PATH, adding shutil.which
> Why did you add this dependency? For example, subprocess is able to
> locate a program if the program has no full path. We don't need a
> which function.

While the Windows API call is part of Windows and the open program always present on Mac OS X, xdg-open is an optional program on free OSes, so I thought we?d need shutil.which to look before we leap.  The alternative is to call Popen(['xdg-open', etc.]) and check if we get ENOENT, but I don?t know if this would be non-ambiguous (for example, do we get ENOENT if xdg-open exists but not the file?).

A related question: what to do when we?re not on Windows nor Mac and xdg-open doesn?t exist?  Raise NotImplemented?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:31:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:31:05 +0000
Subject: [issue6786] readline and zero based indexing
In-Reply-To: <1251310656.11.0.667090107201.issue6786@psf.upfronthosting.co.za>
Message-ID: <1310743865.89.0.813738867542.issue6786@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I'd be writing a patch which would allow a programmer the option to
> explicitly use/instantiate the library in a zero-based way. [...]
> Would this be reasonable?

I think not.  Mark already stated his opposition to ?a crazy level of micro control?.  Such a patch would not be trivial but would not bring much.

I hope you?ll find other bugs that motivate you for a patch! :)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6786>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:32:13 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 15:32:13 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310743933.86.0.0253075482098.issue12561@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

I am attaching an updated patch.  This version specifically checks for __hpux, and the macro name has been changed to avoid clashing with other uses.

----------
Added file: http://bugs.python.org/file22663/getpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:35:32 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 15 Jul 2011 15:35:32 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1310744132.21.0.496608510093.issue1813@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/issue1813>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:36:29 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 15 Jul 2011 15:36:29 +0000
Subject: [issue12571] Python built on Linux 3.0 doesn't include DLFCN
In-Reply-To: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>
Message-ID: <1310744189.32.0.363121277064.issue12571@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/issue12571>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:36:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 15:36:50 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310744210.31.0.646834900292.issue12561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Use >L"" CONSTANT< to decode a byte string to a character string doesn't work with non-ASCII strings. _Py_char2wchar() should be used instead: see for example this fix, commit 5b6e13b6b473.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:40:25 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 15:40:25 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>


New submission from Jim Schneider <jim.schneider at dataflux.com>:

The C compiler that comes with HP/UX 11 has some shortcomings that prevent building Python 3.2.1 out of the box.  I am attaching patches here as I work through issues.

The first patch fixes namespace shortcomings when trying to use struct termios.

----------
components: Build
files: termios.patch
keywords: patch
messages: 140423
nosy: jschneid
priority: normal
severity: normal
status: open
title: HP/UX compiler workarounds
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file22664/termios.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:44:03 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 15:44:03 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310744643.25.0.0957561705788.issue12561@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

I am collecting HP/UX compiler bug workarounds in issue 12572.

Stinner - is the patch you mentioned in a released version of Python 3.2?  Also, how is it affected by the fact that the (wide char) strings in question are constants?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:44:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 15:44:31 +0000
Subject: [issue9408] curses: Link against libncursesw instead of libncurses
In-Reply-To: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>
Message-ID: <1310744671.18.0.405786371753.issue9408@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, I filed the following bug against Mageia's libreadline:
https://bugs.mageia.org/show_bug.cgi?id=2156

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9408>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:45:51 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 15:45:51 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310744751.62.0.245836504436.issue5999@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

I am collecting HP/UX compiler workarounds in issue 12572.  I will be adding patches to it as I produce them, including a patch to fix this on HP/UX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:47:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 15:47:33 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310744853.8.0.991620929085.issue12572@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/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:47:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 15:47:41 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
	used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1310744861.37.0.0140860361865.issue5999@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/issue5999>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:53:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:53:53 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1310745233.29.0.274153102869.issue12417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t have clones of 2.6 and 3.1, so Benjamin, would you commit this?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:55:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 15:55:00 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310745300.66.0.923704725075.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It looks like we don?t have refleaks anymore!  I still have one question.

Victor reported some time ago that packaging.util._path_created was a cache that was never cleared; I fixed that in 27a70dfc38cc, but recently I?ve found that regrtest itself clears the similar distutils.util._path_created; I wonder which approach is better: one global cleaning in regrtest or piecemeal cleanup in each leaking test case?

I?ve also made a patch to register the caches used by packaging.database with the regrtest unclean environment warning; can someone review it?

----------
Added file: http://bugs.python.org/file22665/packaging-caches.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:55:41 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 15:55:41 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310745341.77.0.0595431747309.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

This patch works around the problem underlying issue 5999 by making sure the __STDC_VERSION__ macro is defined and has a value of at least 199901

----------
Added file: http://bugs.python.org/file22666/fileutils.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:56:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 15:56:08 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310745368.9.0.185999510482.issue12572@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You may the number of this issue in a comment of your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 17:59:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 15:59:44 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310745584.2.0.137091156146.issue12572@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops. You may *add* the number of this issue in a comment of your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:00:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 16:00:09 +0000
Subject: [issue6743] pprint.pprint should support no objects to print blank
	lines & allow args
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1310745609.08.0.163229439202.issue6743@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s a first draft at a patch.  I?ve added a module-level print function and a PrettyPrinter.print method which does the real work.

The functions have a signature compatible with print, but I have changed one default value: sep defaults to ',\n', because I think that the output is more useful and more pleasing (otherwise you?d have strange-looking indentation with containers).

If this looks good, I?ll work on doc and tests.  I guess I?ll reuse the helpers in test_print.

----------
keywords: +patch
stage:  -> needs patch
Added file: http://bugs.python.org/file22667/pprint-print.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:00:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 16:00:51 +0000
Subject: [issue6743] Add function compatible with print to pprint module
In-Reply-To: <1250778066.89.0.880851114314.issue6743@psf.upfronthosting.co.za>
Message-ID: <1310745651.57.0.124629236712.issue6743@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: pprint.pprint should support no objects to print blank lines & allow args -> Add function compatible with print to pprint module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6743>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:01:56 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 16:01:56 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310745716.23.0.466800457888.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Workaround for compiler bug; HP/UX compiler refuses to past (implicitly char *) string constants with wide (wchar_t *) string constants.  This patch is also pasted to issue 12561 (which should be closed).

Note:  There is disagreement as to the best way to proceed on this issue.  Stinner (aka haypo) has a patch that should work with non ASCII character sets, and my patch will almost certainly not work in those cases.  YMMV.

----------
Added file: http://bugs.python.org/file22668/getpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:02:36 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 16:02:36 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310745756.61.0.0700407073718.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Sorry - last comment should have been "compiler refuses to past*e*", not "past".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:04:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 16:04:11 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310745851.62.0.162610105675.issue12572@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that getpath.patch is wrong (it's just a workaround hiding a real bug): see msg140422 of the issue #12561.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:05:02 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 16:05:02 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310745902.62.0.0595974590724.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

This patch just reduces compiler noise by explicitly casting pointers to void *.  I expect the Visual Studio C/C++ compiler suite also issued these warnings, too.

----------
Added file: http://bugs.python.org/file22669/typeobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:05:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 16:05:43 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1310745943.52.0.931549886077.issue1626300@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In distutils docs, I?ve mentioned ?setup.py thing? as an alternative to ?python setup.py thing? on Windows.  For packaging, the situation is different: there is no local script anymore, people will have to invoke the global pysetup command.  Would it work if I add a note like this:

  In order to run pysetup commands, you need to add the Python Scripts
  directory to your PATH *include link to relevant section of
  docs.python.org/using*.

BTW, do scripts work without file extensions, or does the installer add .py?  If it?s the latter, then my doc note will need to mention that too.

----------
nosy: +terry.reedy
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:07:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 16:07:02 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1310746022.47.0.584911883046.issue12141@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, doesn?t the change to Makefile.pre.in need to be ported to the MSI build system too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:07:32 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 16:07:32 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310746052.34.0.0845851985903.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

The HP/UX C compiler grumbles when a symbol that is declared static is later defined without the static storage class specifier.  The attached patch just adds the missing "static" keywords.

----------
Added file: http://bugs.python.org/file22670/Python-ast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:12:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 16:12:24 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1310746344.61.0.536939951262.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
hgrepos: +42

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:12:49 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 16:12:49 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310746369.54.0.929605671777.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

I'm adding the original listeners for issue 5999 to this one.

The fileutils.patch patch attached to this issue directly addresses what's wrong in issue 5999; I'd consider it closed, but as I didn't open it, and I'm not actually part of the python project, that's not my call to make.

----------
nosy: +eric.araujo, loewis, srid, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:14:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Jul 2011 16:14:34 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310746474.63.0.718419142977.issue12561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Stinner - is the patch you mentioned in a released version
> of Python 3.2?

Yes, Python 3.2.1. (It's not part of Python 3.1.)

> Also, how is it affected by the fact that the (wide char) strings
> in question are constants?

I don't remember exactly. My patch uses the locale encoding at runtime instead of using the locale encoding of the compiler. See issue #6011 for the details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:16:15 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 16:16:15 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310746575.0.0.475057761212.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

>From issue 12561 (which I will be closing):

Author: STINNER Victor (haypo) *  Date: 2011-07-15 15:36  
Use >L"" CONSTANT< to decode a byte string to a character string doesn't work with non-ASCII strings. _Py_char2wchar() should be used instead: see for example this fix, commit 5b6e13b6b473. 

This is in reference to getpath.patch.  I have no need to support internationalized versions of the constant strings my patch addresses, so Stinner's commit is overkill for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:17:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 16:17:15 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310746635.48.0.132644059626.issue12572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Minor note: we prefer unified diffs, and when possible, all related changes in one file.  See http://docs.python.org/devguide/

I can?t review the patches, as I don?t know C nor HP/UX.  I?m not sure why you opened this report instead of following on the other one :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:19:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Jul 2011 16:19:36 +0000
Subject: [issue12526] packaging.pypi.Crawler and resulting objects have a
	circular API
In-Reply-To: <1310312448.84.0.700662725694.issue12526@psf.upfronthosting.co.za>
Message-ID: <1310746776.46.0.406806424856.issue12526@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  I noticed similar strangeness in the API when working on the documentation.  Alexis is quite busy these weeks, but he will with no doubt comment on this later.

I?m not sure the force argument is a good idea; I think we should ask ourselves what is the behavior that would be most intuitive for users, and implement that.  If there are performance or caching issues, we?ll see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12526>
_______________________________________

From report at bugs.python.org  Fri Jul 15 18:41:19 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 16:41:19 +0000
Subject: [issue12561] Compiler workaround for wide string constants in
	Modules/getpath.c (patch)
In-Reply-To: <1310666381.22.0.322884709649.issue12561@psf.upfronthosting.co.za>
Message-ID: <1310748079.62.0.616949976535.issue12561@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Constant initializers are required to be constants, not function calls, so _Py_char2wchar cannot be used in the definition of lib_python (line #138 of Modules/getpath.c).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12561>
_______________________________________

From report at bugs.python.org  Fri Jul 15 19:29:07 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 17:29:07 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310750947.6.0.914891424634.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Update to getpath.patch (issue 12561) - this version uses _Py_char2wchar where possible.  Unfortunately, as lib_python is declared and defined statically, this can't be used in both cases where the HP/UX compiler has issues.

----------
Added file: http://bugs.python.org/file22671/getpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 19:34:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 15 Jul 2011 17:34:13 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1310751253.93.0.505948371246.issue12556@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

A couple remarks:
- if st_size == 0, then you have to specify an explicit length (your example passes 0, which would fail with EINVAL without the check)
- most enties in /proc don't support mmap file operation, so it's likely to fail anyway (with ENODEV, EACCESS...). Do you have an example of a /proc entry with st_size == 0 that can be mmapped (mapping /proc/sys/debug/exception-trace fails with EACCESS)?

> How about adding a keyword argument to `mmap.mmap()`, which disables
> fstat-based size checks?

I don't like the idea of adding an argument which doesn't have a counterpart in the POSIX version (especially to address such corner cases).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:01:24 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 15 Jul 2011 18:01: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: <1310752884.55.0.0539713204772.issue11254@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

FWIW, I've filed a bug about this issue for Fedora 15's python3 package here: https://bugzilla.redhat.com/show_bug.cgi?id=722578

Looks like this has led to an extra .pyc in the old location for every Python 3 .py file in Fedora 15's various python3-* rpm packages (as generated by distutils).  

rpm's post-processing has been generating .pyc files in the (correct) __pycache__ location (via rpmbuild's brp-python-bytecompile script, which uses "compileall").

For examples, see that Fedora bug report; so far it's affected every built rpm I've looked at.

I believe the impact of the extra .pyc files is merely wasted disk space within our rpm-packaged Python 3.2 stack.

I'm thinking of applying the patch to our downstream python3.src.rpm

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:09:41 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 15 Jul 2011 18:09:41 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310753381.37.0.812951076691.issue12524@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

There's also http://httpstat.us/. You can send any request (also POST) to http://httpstat.us/200 and it gives you a 200 OK response.

I recall seeing other similar services, but didn't find them quickly.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:14:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 18:14:24 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310649963.32.0.0189334744199.issue12551@psf.upfronthosting.co.za>
Message-ID: <1310753595.3647.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This patch is functionally equivalent, but advertises 'tls-unique'
> support in a bit different way.
> 
> HAS_TLS_UNIQUE is not exposed in the python 'ssl' module, instead a
> list 'CHANNEL_BINDING_TYPES' is provided (empty when 'tls-unique' is
> not supported). get_channel_binding raises ValueError if the argument
> is not on this list. This way the API can be extended to other channel
> binding types without adding new constants or functions. Adding a new
> channel binding type would not need any modifications in the API
> client code (if it is designed to use arbitrary cb types).

Thanks, this is a good idea. I'm trying to get advice on the
openssl-users mailing-list about this and will commit if I don't get any
contradicting info soon ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:16:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 18:16:56 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1310745300.66.0.923704725075.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310753748.3647.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I?ve also made a patch to register the caches used by
> packaging.database with the regrtest unclean environment warning; can
> someone review it?

I would call .copy() on the original dicts rather than remembering an
explicit empty dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:36:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jul 2011 18:36:40 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1310755000.24.0.919774467148.issue1626300@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Windows, scripts run with whatever name -- no extension or other extensions. I have tested this from both IDLE and command line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:46:28 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 15 Jul 2011 18:46:28 +0000
Subject: [issue12529] cgi.parse_header fails on double quotes and semicolons
In-Reply-To: <1310331365.35.0.0304262740475.issue12529@psf.upfronthosting.co.za>
Message-ID: <1310755588.52.0.468440044251.issue12529@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch against 2.7. It adds Ben's example as a test case, and his one-line change to the _parseparam helper function to fix the issue.

----------
components: +Library (Lib)
keywords: +needs review, patch
nosy: +petri.lehtinen
stage:  -> patch review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22672/issue12529.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12529>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:48:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jul 2011 18:48:03 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310755683.1.0.389649043603.issue12572@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>The fileutils.patch patch attached to this issue directly addresses what's wrong in issue 5999; I'd consider it closed, ...

When an patch is committed that fixes that issue, say so there and I or someone will close it.

>From issue 12561 (which I will be closing):...
so Stinner's commit is overkill for me.

Issues sometimes expand beyond the original request. It is unclear to me whether Victor thinks that that issue is finished. If he thinks more should be done, then I think it should be left open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:48:37 2011
From: report at bugs.python.org (Nasos Dousis)
Date: Fri, 15 Jul 2011 18:48:37 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za>
Message-ID: <1310755717.46.0.673674957091.issue10910@psf.upfronthosting.co.za>


Nasos Dousis <ndousis at gmail.com> added the comment:

Ronald,

Thanks much for your help and insight.  I tried the patch but unfortunately it didn't work for me-- this might be because I have Python extensions written in C++.

Any other suggestions?  Should I wait for the next version of boost.python?

Thanks and regards,
Nasos

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:52:22 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 15 Jul 2011 18:52:22 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1310755942.38.0.730414109076.issue12541@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12541>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:53:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 18:53:12 +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: <1310755992.18.0.416307184808.issue11343@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks like a rather good idea, although I'm not sure it deserves a new global exception type.

----------
nosy: +benjamin.peterson, ncoghlan, pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:54:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 18:54:09 +0000
Subject: [issue11824] freeze.py broken due to ABI flags
In-Reply-To: <1302488520.76.0.698152823885.issue11824@psf.upfronthosting.co.za>
Message-ID: <1310756049.65.0.798325325062.issue11824@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Barry?

Additionally, if would be nice if we got some tests for the "freeze" tool, otherwise I fear we will keep breaking it.

----------
nosy: +pitrou
priority: normal -> high
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11824>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:54:39 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 15 Jul 2011 18:54:39 +0000
Subject: [issue12570] BaseHTTPServer.shutdown() locks if the last request 404'd
In-Reply-To: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>
Message-ID: <1310756079.16.0.71917992718.issue12570@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12570>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:54:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 18:54:52 +0000
Subject: [issue11829] inspect.getattr_static code execution with
	meta-metaclasses
In-Reply-To: <1302562001.85.0.31491141999.issue11829@psf.upfronthosting.co.za>
Message-ID: <1310756092.88.0.745968570864.issue11829@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ncoghlan
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11829>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:55:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 18:55:32 +0000
Subject: [issue11813] inspect.getattr_static doesn't get module attributes
In-Reply-To: <1302389059.87.0.554654770337.issue11813@psf.upfronthosting.co.za>
Message-ID: <1310756132.63.0.381318943284.issue11813@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/issue11813>
_______________________________________

From report at bugs.python.org  Fri Jul 15 20:56:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 18:56:24 +0000
Subject: [issue11770] inspect.dir_static
In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za>
Message-ID: <1310756184.0.0.723909014607.issue11770@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11770>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:03:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jul 2011 19:03: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: <E1QhnfY-00037T-Mt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1ae0b7b8de0b by Antoine Pitrou in branch '3.2':
Issue #11321: Fix a crash with multiple imports of the _pickle module when
http://hg.python.org/cpython/rev/1ae0b7b8de0b

New changeset 6674272754da by Antoine Pitrou in branch 'default':
Issue #11321: Fix a crash with multiple imports of the _pickle module when
http://hg.python.org/cpython/rev/6674272754da

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:04:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 19:04: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: <1310756649.97.0.3112819891.issue11321@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now, thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:07:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jul 2011 19:07:04 +0000
Subject: [issue11627] segfault raising an arbitrary object as an exception
In-Reply-To: <1300744765.64.0.0214361659325.issue11627@psf.upfronthosting.co.za>
Message-ID: <E1Qhnj4-0003TV-OR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8d05f697acd4 by Benjamin Peterson in branch '3.2':
catch nasty exception classes with __new__ that doesn't return a exception (closes #11627)
http://hg.python.org/cpython/rev/8d05f697acd4

New changeset bc1fbd6f667a by Benjamin Peterson in branch 'default':
merge 3.2 (#11627)
http://hg.python.org/cpython/rev/bc1fbd6f667a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11627>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:10:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jul 2011 19:10:56 +0000
Subject: [issue11627] segfault raising an arbitrary object as an exception
In-Reply-To: <1300744765.64.0.0214361659325.issue11627@psf.upfronthosting.co.za>
Message-ID: <E1Qhnmo-0003qb-SA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 45b1ae1ef318 by Benjamin Peterson in branch '2.7':
port 8d05f697acd4 (#11627)
http://hg.python.org/cpython/rev/45b1ae1ef318

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11627>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:16:30 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 15 Jul 2011 19:16:30 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1310757390.1.0.966115800336.issue12559@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> If we go this way, the "errors" and "newline" argument should be added
> as well.

Yeah, I thought about that. I can make a new patch, that implement this, if needed. Though it seems there is a real problem, the one that Amaury Forgeot d'Arc mentioned. I can't think of a way to solve it in a backwards compatible way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12559>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:21:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jul 2011 19:21:05 +0000
Subject: [issue11603] Python crashes or hangs when rebinding __repr__ as
	__str__
In-Reply-To: <1300482917.38.0.116490632242.issue11603@psf.upfronthosting.co.za>
Message-ID: <E1Qhnwe-0004ji-6M@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b488e027c952 by Antoine Pitrou in branch '3.1':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/b488e027c952

New changeset 8b52ac4a0c9f by Antoine Pitrou in branch '3.2':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/8b52ac4a0c9f

New changeset 0a040aa9bb34 by Antoine Pitrou in branch 'default':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/0a040aa9bb34

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11603>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:24:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jul 2011 19:24:05 +0000
Subject: [issue11603] Python crashes or hangs when rebinding __repr__ as
	__str__
In-Reply-To: <1300482917.38.0.116490632242.issue11603@psf.upfronthosting.co.za>
Message-ID: <E1QhnzW-0004vh-Ag@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cd9eca1bf531 by Antoine Pitrou in branch '2.7':
Issue #11603: Fix a crash when __str__ is rebound as __repr__.
http://hg.python.org/cpython/rev/cd9eca1bf531

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11603>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:24:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 19:24:48 +0000
Subject: [issue11603] Python crashes or hangs when rebinding __repr__ as
	__str__
In-Reply-To: <1300482917.38.0.116490632242.issue11603@psf.upfronthosting.co.za>
Message-ID: <1310757888.73.0.270000864457.issue11603@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed, now, thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11603>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:25:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jul 2011 19:25:51 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1310757951.29.0.925939252566.issue12531@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is just the tip of the iceberg as far as needed symbol index entries goes. Nearly 3 years ago, I wrote a Python 3 symbol glossary "Python3 Syntax Symbol Uses" that was complete as far as I knew then. I think most of the entries there should have a corresponding index entry in the official docs. Link to download/view is

https://code.google.com/p/xploro/downloads/detail?name=PySymbols.html&can=1&q=

That has 7 entries for '*':
  *: In function parameter list, make following unstarred names keyword only.
P *parameter_name: Function parameter bound to a tuple of extra positional arguments, any following unstarred names are keyword only.
P *iterable: In a call, unpack iterable items as arguments.
P *assignment_target: Starred target in assignment statement gets extra items from iterable.
I number1 * number2: Number multiplication operator.
I n * sequence or sequence * n: Operator to concatenate n copies of sequence.
S from module import *: Import all public (non-private) names from the module. 

 /P/I/S == 'nofix', prefix, infix, suffix.

I have been planning to work on a patch 'sometime', but would be happy if someone else grabbed the above and ran with it (and expanded the title of this issue).

I believe existing docs can get additions like this.

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:30:40 2011
From: report at bugs.python.org (Jim Schneider)
Date: Fri, 15 Jul 2011 19:30:40 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310758240.03.0.198536534836.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Terry - I apologize for jumping the gun a bit, and let me be a bit more clear.  When I realized that the HP/UX compiler was going to have as many problems as it does compiling python 3, I decided it would be best to create a single issue for all of the compiler issues.  In retrospect, opening an issue for the single compiler bug discussed in issue 12561 was a mistake, and I had hoped to migrate the discussion of that issue here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:39:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jul 2011 19:39:07 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310758747.99.0.0473440710473.issue12533@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The pastebin link gives me a blank box. In any case, a one-month retention does not work for the tracker. If you do get an error traceback indicating an error in CPython or its library, post it here. However, your post so far strongly suggests that the error is elsewhere, so we will close this in a week or so if nothing concrete is added.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:47:06 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Jul 2011 19:47:06 +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: <1310759226.45.0.250145889432.issue11343@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Just make it a SyntaxError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:48:27 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Jul 2011 19:48:27 +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: <1310759307.76.0.426834476574.issue11343@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Oh, I see Martin disagrees. SyntaxError is raised for anything which Python won't compile. For example, too many arguments gets a SyntaxError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:48:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jul 2011 19:48:45 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310759325.83.0.576474552366.issue12535@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Nick's rationale for the current order, and also like his idea of indicating that the first traceback is truncated (which has not been completely obvious to me). Bike-shedding a bit, I would prefer something more like:

Truncated traceback of caught exception:

The '(most recent call last)' bit is nonsensical when only the most recent call is given.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Fri Jul 15 21:56:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 19:56:34 +0000
Subject: [issue12573] add resource checks for dangling threads and processes
In-Reply-To: <1310759794.84.0.887335776522.issue12573@psf.upfronthosting.co.za>
Message-ID: <1310759794.84.0.887335776522.issue12573@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch adds resource checks for dangling Thread and Process objects to the test suite runner. This should make it easier to spot the cause of some potential sporadic reference leaks.

----------
components: Tests
files: dangling.patch
keywords: patch
messages: 140472
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: add resource checks for dangling threads and processes
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22673/dangling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12573>
_______________________________________

From report at bugs.python.org  Fri Jul 15 22:16:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jul 2011 20:16:52 +0000
Subject: [issue12573] add resource checks for dangling threads and processes
In-Reply-To: <1310759794.84.0.887335776522.issue12573@psf.upfronthosting.co.za>
Message-ID: <E1Qhood-0000o2-0u@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2bedea96de60 by Antoine Pitrou in branch '3.2':
Issue #12573: Add resource checks for dangling Thread and Process objects.
http://hg.python.org/cpython/rev/2bedea96de60

New changeset 86dc49fbf4af by Antoine Pitrou in branch 'default':
Issue #12573: Add resource checks for dangling Thread and Process objects.
http://hg.python.org/cpython/rev/86dc49fbf4af

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12573>
_______________________________________

From report at bugs.python.org  Fri Jul 15 22:26:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jul 2011 20:26:30 +0000
Subject: [issue12573] add resource checks for dangling threads and processes
In-Reply-To: <1310759794.84.0.887335776522.issue12573@psf.upfronthosting.co.za>
Message-ID: <1310761590.58.0.805696148984.issue12573@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12573>
_______________________________________

From report at bugs.python.org  Fri Jul 15 22:28:32 2011
From: report at bugs.python.org (Garen)
Date: Fri, 15 Jul 2011 20:28:32 +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: <1310761712.47.0.137239595642.issue7833@psf.upfronthosting.co.za>


Changes by Garen <garen.parham at gmail.com>:


----------
nosy: +Garen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Fri Jul 15 22:36:02 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Jul 2011 20:36:02 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1310762162.14.0.0691909512391.issue12531@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Fri Jul 15 22:38:39 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Jul 2011 20:38:39 +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: <1310762319.47.0.275179512063.issue11343@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Fri Jul 15 22:53:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jul 2011 20:53:13 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1310763193.19.0.209348835211.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I just 'upgraded' to 3.2.1 on my XP machine and I see the same with F5-run, which restarts before running the saved file. This appears to be a nasty regression from 3.2.0 that should have been a release blocker if caught earlier. I believe it merits a quick re-release, once fixed, of either the Windows binary or Python itself depending on whether this is windows specific or not.

The normal behavior when starting IDLE is 2 pythonw.exe processes -- one to run IDLE itself and the other for the attached process that runs user code. Restart/Run starts a third process with a fresh interpreter for user code and the old, orphaned user process should and usually does disappear in 2-3 seconds (on my old, slow machine). (There are tracker issues about this not always happening when a runaway process is stopped with ^C, but is has always worked otherwise.) Each process appears to take about 10+Mb, so anyone doing rapid code/test iterations, as I sometimes do, could easily overfill physical memory. 
Closing the IDLE windows does not stop the detached processes, so they have to be killed 1 at a time with 3 clicks each or by rebooting. Neither is pleasant.

Although I should have 3.2.1 loaded at least for reviewing issues, I plan to revert to 3.2.0.

Victor: do you know of any way to test for process extinction on Windows?

----------
nosy: +georg.brandl, haypo, kbk, loewis, terry.reedy
priority: normal -> critical
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Fri Jul 15 22:57:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Jul 2011 20:57:11 +0000
Subject: [issue12558] Locale-dependent exception for float width argument to
	Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1310763431.59.0.572622747046.issue12558@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Locale-dependent crash for float width argument to Tkinter widget constructor -> Locale-dependent exception for float width argument to Tkinter widget constructor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Fri Jul 15 23:00:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Jul 2011 21:00:10 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1310763610.09.0.671876211802.issue12540@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 16 01:25:48 2011
From: report at bugs.python.org (Rafe Kettler)
Date: Fri, 15 Jul 2011 23:25:48 +0000
Subject: [issue12574] Documentation for Queue in 2.x has an incorrect title
In-Reply-To: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>
Message-ID: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>


New submission from Rafe Kettler <rafe.kettler at gmail.com>:

The documentation for Queue in all versions of Python 2.7 and 2.6 (see http://docs.python.org/release/2.6.7/library/queue.html#module-Queue for the 2.7 docs) has the title "queue -- A synchronized queue class." The module, however, is named "Queue" in all of 2.x. So, while the title is appropiate for 3.x, it's incorrect for 2.x.

I can make a patch, as well.

----------
assignee: docs at python
components: Documentation
messages: 140475
nosy: docs at python, rafe.kettler
priority: normal
severity: normal
status: open
title: Documentation for Queue in 2.x has an incorrect title
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12574>
_______________________________________

From report at bugs.python.org  Sat Jul 16 03:23:38 2011
From: report at bugs.python.org (=?utf-8?q?Kristoffer_Grundstr=C3=B6m?=)
Date: Sat, 16 Jul 2011 01:23:38 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310779418.29.0.0886591494699.issue12533@psf.upfronthosting.co.za>


Kristoffer Grundstr?m <kristoffer.grundstrom1983 at gmail.com> added the comment:

Here's the link to the Imprudence bugzilla: http://redmine.kokuaviewer.org/issues/1025

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Sat Jul 16 04:06:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Jul 2011 02:06:05 +0000
Subject: [issue12273] Change ast.__version__ calculation	to provide consistent
	ordering
In-Reply-To: <1307419934.4.0.45216742345.issue12273@psf.upfronthosting.co.za>
Message-ID: <E1QhuGa-00063c-F6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b23ad0a6cf87 by Benjamin Peterson in branch 'default':
remove ast.__version__ (closes #12273)
http://hg.python.org/cpython/rev/b23ad0a6cf87

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12273>
_______________________________________

From report at bugs.python.org  Sat Jul 16 09:40:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 07:40:00 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1310802000.46.0.606302000488.issue12535@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The redundancy of the "(most recent call last)" when there's only one frame in the stack is a separate problem (as it happens even for unchained tracebacks), but feel free to create a new issue if you'd like to see it changed (I expect it would needlessly break doctests, so I don't like your chances of getting agreement on it, though)

+1 for the short and to the point "Truncated traceback" phrasing in the header line to address the current issue, though.

I've removed 3.2 from the affected releases due to the same "may break doctests" concern (error handling doctests are so inherently fragile that I don't mind breaking cases like this in a major version upgrade)

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12535>
_______________________________________

From report at bugs.python.org  Sat Jul 16 09:56:42 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 07:56:42 +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: <1310803002.01.0.261332996509.issue11343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

+1 for a new exception type to indicate "this may technically be legal Python, but this Python implementation cannot handle it correctly"

Whatever exception type we add, it would be nice to also be able to use it if someone eventually fixes the compiler recursion crasher, so I'd like to paint this particular bikeshed as the more general "SyntaxLimitError".

Possible docs phrasing:

exception:: SyntaxLimitError

Raised when the compilation and code generation process encounters an error due to internal limitations of the current implementation (e.g. the CPython parser has an upper limit on the number of nested sets of parentheses it can handle in a single expression, but no such limitation exists in the Python language reference).
This is a subclass of :exc:`SyntaxError`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 10:24:37 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Jul 2011 08:24:37 +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: <1310804677.49.0.263793014451.issue11343@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I like SyntaxLimitError much better than ParserError.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 10:26:55 2011
From: report at bugs.python.org (Bharadwaj)
Date: Sat, 16 Jul 2011 08:26:55 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310804815.69.0.961851153364.issue12524@psf.upfronthosting.co.za>


Changes by Bharadwaj <barbi.bruce at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22674/http_example.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Sat Jul 16 10:41:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Jul 2011 08:41:11 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310805671.41.0.489171073354.issue12524@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

httpstat.us is has been registered quite recently, and is titled as an "experiment" in the footer.  I'd rather use something more likely to be persistent.  bugs.python.org seems a better choice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Sat Jul 16 11:04:03 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Jul 2011 09:04:03 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1310807043.84.0.00492707140306.issue12434@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The difference between 2.6 and 2.7 stems from the rewrite of the IO library in C that was made for 2.7

The error Terry sees gets thrown here (in Modules/_io/stringio.c):

    if (!PyUnicode_Check(obj)) {
        PyErr_Format(PyExc_TypeError, "string argument expected, got '%s'",
                     Py_TYPE(obj)->tp_name);
        return NULL;
    }

Therefore, I propose to change this error message to:

"unicode argument expected, got '%s'"

as Terry suggested.

Adding Antoine, Benjamin and Daniel (listed as experts on IO) to nosy.

Is there an objection to making this change in the error message?

----------
nosy: +benjamin.peterson, pitrou, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From senthil at uthcode.com  Sat Jul 16 11:06:29 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sat, 16 Jul 2011 17:06:29 +0800
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310805671.41.0.489171073354.issue12524@psf.upfronthosting.co.za>
References: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
	<1310805671.41.0.489171073354.issue12524@psf.upfronthosting.co.za>
Message-ID: <20110716090628.GA2302@mathmagic>

Also, it does not say or "advertise" about POST, it gives examples for
GET. I find Ezio's suggestion using bugs.python.org as a good one.

From report at bugs.python.org  Sat Jul 16 11:06:36 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Jul 2011 09:06:36 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310805671.41.0.489171073354.issue12524@psf.upfronthosting.co.za>
Message-ID: <20110716090628.GA2302@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Also, it does not say or "advertise" about POST, it gives examples for
GET. I find Ezio's suggestion using bugs.python.org as a good one.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Sat Jul 16 11:30:21 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Jul 2011 09:30:21 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1310808621.02.0.355902187228.issue12531@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Peter, doesn't your patch also refer to the meaning of * and ** in function definitions?  

I would argue that the missing reference is to a paragraph further down:

   [...] If the syntax *expression appears in the function call, expression must evaluate to a sequence. Elements from this sequence [...]

Terry, the glossary you compiled certainly looks comprehensive. However, I wouldn't delay local fixes like the one discussed here until "the grand scheme" is committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Sat Jul 16 11:49:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 09:49:04 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1310809744.95.0.76823236595.issue10271@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/issue10271>
_______________________________________

From report at bugs.python.org  Sat Jul 16 11:59:21 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jul 2011 09:59:21 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310810361.17.0.167863043024.issue12572@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please don't manage independent bugs in a single issue, even if they are related. The way this is done here will it make hard to track what exactly has been done, and what needs to be done.

As it stands, please combine all patches into a single one, and we won't commit anything until the entire patch passes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Sat Jul 16 12:02:02 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jul 2011 10:02:02 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1310810522.31.0.202187149782.issue12540@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Terry, please don't overreact. Nobody has noticed it during the *long* rc period of 3.2.1, so it can't be that bad. Actually, I *did* notice, but didn't have the time to submit a bug report.

----------
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 16 12:02:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jul 2011 10:02:59 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1310810579.35.0.376990125395.issue12540@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

FWIW, it only happens with IDLE; python.exe seems to terminate fine when done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 16 12:17:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jul 2011 10:17:24 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1310811444.65.0.385854872346.issue12568@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In the #2382 code, how is the Windows case supposed to work? Also, what about systems that don't have wcswidth? IOW, the patch appears to be incorrect.

I like the #6755 approach better, except that it shouldn't be using hard-coded tables, but instead integrate with Python's version of the UCD. In addition, it should use an accepted, published strategy for determining the width, preferably coming from the Unicode consortium.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Sat Jul 16 12:24:00 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 16 Jul 2011 10:24:00 +0000
Subject: [issue12273] Change ast.__version__ calculation	to provide consistent
	ordering
In-Reply-To: <1307687297.17.0.74781332947.issue12273@psf.upfronthosting.co.za>
Message-ID: <4E2166BE.4020608@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> sys.version_info and sys._mercurial provide all the info needed for someone (like me for mnfy)

Can you please elaborate? How do you know from looking at
sys._mercurial whether you can support that AST version?
sys._mercurial changes with every commit, but the AST doesn't
change that often.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12273>
_______________________________________

From report at bugs.python.org  Sat Jul 16 12:38:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 10:38:00 +0000
Subject: [issue12273] Change ast.__version__ calculation to provide consistent
	ordering
In-Reply-To: <4E2166BE.4020608@v.loewis.de>
Message-ID: <CADiSq7d-qmfya_riBm2sMqrSDvuvqNxMwqi_5xHkV=-e3j4pHw@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Sat, Jul 16, 2011 at 8:24 PM, Martin v. L?wis <report at bugs.python.org> wrote:
>> sys.version_info and sys._mercurial provide all the info needed for someone (like me for mnfy)
>
> Can you please elaborate? How do you know from looking at
> sys._mercurial whether you can support that AST version?
> sys._mercurial changes with every commit, but the AST doesn't
> change that often.

For anyone not following CPython tip, the real version indicator is
sys.version_info (i.e. assuming the AST changes with each major Python
version and bumping your version check once you've determined that
your code is compatible with a later release).

Life is more difficult for anyone following CPython tip, but in that
case it is probably easier to just assume compatibility and
investigate further if a "hg pull" ever breaks anything. Since
"ast.__version__" wasn't usefully orderable post-Hg migration, the
previous best you could have done is checked for a specific version,
guaranteeing failure if we changed the AST in any respect. Agreed that
sys._mercurial changes too often to be useful in even that limited
way, though.

----------
title: Change ast.__version__ calculation	to provide consistent ordering -> Change ast.__version__ calculation to provide consistent ordering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12273>
_______________________________________

From report at bugs.python.org  Sat Jul 16 12:42:10 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 16 Jul 2011 10:42:10 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1310812930.64.0.201508505546.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sorry for the late reply: I've applied ?ric comments made on Rietveld.

----------
Added file: http://bugs.python.org/file22675/shutil_chown-default-v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Sat Jul 16 12:43:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jul 2011 10:43:32 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1310807043.84.0.00492707140306.issue12434@psf.upfronthosting.co.za>
Message-ID: <1310812943.3630.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The error Terry sees gets thrown here (in Modules/_io/stringio.c):
> 
>     if (!PyUnicode_Check(obj)) {
>         PyErr_Format(PyExc_TypeError, "string argument expected, got '%s'",
>                      Py_TYPE(obj)->tp_name);
>         return NULL;
>     }
> 
> Therefore, I propose to change this error message to:
> 
> "unicode argument expected, got '%s'"
> 
> as Terry suggested.
> 
> Adding Antoine, Benjamin and Daniel (listed as experts on IO) to nosy.
> 
> Is there an objection to making this change in the error message?

No, the proposal is right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Sat Jul 16 14:42:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 12:42:49 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1310820169.74.0.234816502661.issue10042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

NotImplemented is a speed and maintainability hack - the runtime cost and additional code complexity involved in doing the same operator signalling via exceptions would be prohibitive (check Objects/abstract.c in the CPython source if you want the gory details).

As far as an implementation of @total_ordering that correctly handles NotImplemented goes, yes, I absolutely agree we should do this correctly. The fact that it is *hard* is an argument in *favour* of us getting it right, as there is a decent chance that manually written comparison operations will also stuff it up.

That said, I don't think sane_total_ordering quite gets the semantics right, either.

Some helper functions in the closure would let the existing lambda functions be updated to do the right thing (and I believe the semantics I have used below are the correct ones for handling NotImplemented in @total_ordering). (I haven't actually run this code as yet, but it should give a clear idea of what I mean)

def not_op(op, other):
   # "not a < b" handles "a >= b"
   # "not a <= b" handles "a > b"
   # "not a >= b" handles "a < b"
   # "not a > b" handles "a <= b"
   op_result = op(other)
   if op_result is NotImplemented:
     return op_result
   return not op_result

def op_or_eq(op, self, other):
   # "a < b or a == b" handles "a <= b"
   # "a > b or a == b" handles "a >= b"
   op_result = op(other)
   if op_result:
     # Short circuit OR, as op is True
     # NotImplemented is also passed back here
     return op_result
   return self.__eq__(other)

def not_op_and_not_eq(op, self, other):
   # "not (a < b or a == b)" handles "a > b"
   # "not a < b and a != b" is equivalent
   # "not (a > b or a == b)" handles "a < b"
   # "not a > b and a != b" is equivalent
   op_result = op(other)
   if op_result:
     # Short circuit AND, as not_op is False
     # NotImplemented is also passed back here
     if op_result is NotImplemented:
       return op_result
     return not op_result
   return self.__ne__(other)

def not_op_or_eq(op, self, other):
   # "not a <= b or a == b" handles "a >= b"
   # "not a >= b or a == b" handles "a <= b"
   op_result = op(other)
   if op_result is NotImplemented:
     return op_result
   if op_result:
     return self.__eq__(other)
   # Short circuit OR, as not_op is True
   return not op_result

def op_and_not_eq(op, self, other):
   # "a <= b and not a == b" handles "a < b"
   # "a >= b and not a == b" handles "a > b"
   op_result = op(other)
   if op_result is NotImplemented:
     return op_result
   if op_result:
     return self.__ne__(other)
   # Short circuit AND, as op is False
   return op_result

The conversion table then looks like:

convert = {
  '__lt__': [
    ('__gt__',
      lambda self, other: not_op_and_not_eq(self.__lt__, self, other)),
    ('__le__',
      lambda self, other: op_or_eq(self.__lt__, self, other)),
    ('__ge__',
      lambda self, other: not_op(self.__lt__, other))
  ],
  '__le__': [
    ('__ge__',
      lambda self, other: not_op_or_eq(self.__le__, self, other)),
    ('__lt__',
      lambda self, other: op_and_not_eq(self.__le__, self, other)),
    ('__gt__',
      lambda self, other: not_op(self.__le__, other))
  ],
  '__gt__': [
    ('__lt__',
      lambda self, other: not_op_and_not_eq(self.__gt__, self, other)),
    ('__ge__',
      lambda self, other: op_or_eq(self.__gt__, self, other)),
    ('__le__',
      lambda self, other: not_op(self.__gt__, other))
  ],
  '__ge__': [
    ('__le__',
      lambda self, other: not_op_or_eq(self.__ge__, self, other)),
    ('__gt__',
      lambda self, other: op_and_not_eq(self.__ge__, self, other)),
    ('__lt__',
      lambda self, other: not_op(self.__ge__, other))
  ]
}

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Jul 16 14:44:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 12:44:57 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1310820297.46.0.559621017357.issue10042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Also, a note regarding efficiency: as it calls the underlying methods directly and avoids recursing through the full operand coercion machinery, I would actually expect this approach to run faster than the current implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Jul 16 16:08:17 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Jul 2011 14:08:17 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1310825297.07.0.461036458998.issue12380@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

On one hand, I agree that the situation isn't intuitive. Why should some methods of bytearray accept bytearrays, and some shouldn't?

On the other hand, this actually has rather deep implementation reasons. 

Methods like 'translate' are implemented in Objects/bytearrayobject.c

On the other hand, ljust, rjust and center are taken from stringlib. Now, stringlib is generic code, and has some strict argument checking. For example, in stringlib_ljust:

    if (!PyArg_ParseTuple(args, "n|c:ljust", &width, &fillchar))
        return NULL;

The 'c' format to PyArg_ParseTuple expects an object that passes PyBytes_Check, IOW a bytes object or a subclass thereof. bytearray is not a subclass of bytes, hence the problem.

The solution could be global, to allow bytearray fit the 'c' format of PyArg_ParseTuple. Then one would also be able to pass a bytearray into other stringlib methods requiring the 'c' format.

One way or the other, this is of course doable. A decision has to be made though - is the nuisance annoying enough to warrant such an API change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Sat Jul 16 16:43:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jul 2011 14:43:35 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <1310803002.01.0.261332996509.issue11343@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o8SqYkBfspQ+QhsNmtVo5rqFVGCKDQkaYcM_25sc9cC9A@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/16 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> +1 for a new exception type to indicate "this may technically be legal Python, but this Python implementation cannot handle it correctly"
>
> Whatever exception type we add, it would be nice to also be able to use it if someone eventually fixes the compiler recursion crasher, so I'd like to paint this particular bikeshed as the more general "SyntaxLimitError".

What is the point of a new exception? When would you ever want to
catch it as opposed to a regular SyntaxError? You're going to have to
change the code either way.

Moreover, all Python implementations are going to have to place some
limits on stack depth and recursion, so it's not really an
implementation detail.

The Python language doesn't make an mention of limited memory, but no
one is going to suggest a MemoryLimitError, which is an
"implementation detail".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 16:51:41 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Jul 2011 14:51:41 +0000
Subject: [issue12574] Documentation for Queue in 2.x has an incorrect title
In-Reply-To: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_J1uVECn0KEqqJiBbVevh-EY-Cfc023fr784PUtF+Yyw@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> The documentation for Queue in all versions of Python 2.7 and 2.6 (see
> http://docs.python.org/release/2.6.7/library/queue.html#module-Queue for
> the 2.7 docs) has the title "queue -- A synchronized queue class." The
> module, however, is named "Queue" in all of 2.x. So, while the title is
> appropiate for 3.x, it's incorrect for 2.x.
>
> I can make a patch, as well.
>

Sure, make a patch for 2.7 (the 2.6 line is now in "security only" mode).

Eli

----------
nosy: +eli.bendersky
Added file: http://bugs.python.org/file22676/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12574>
_______________________________________
-------------- next part --------------
<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The documentation for Queue in all versions of Python 2.7 and 2.6 (see <a href="http://docs.python.org/release/2.6.7/library/queue.html#module-Queue" target="_blank">http://docs.python.org/release/2.6.7/library/queue.html#module-Queue</a> for the 2.7 docs) has the title &quot;queue -- A synchronized queue class.&quot; The module, however, is named &quot;Queue&quot; in all of 2.x. So, while the title is appropiate for 3.x, it&#39;s incorrect for 2.x.<br>


<br>
I can make a patch, as well.<br></blockquote></div><br>Sure, make a patch for 2.7 (the 2.6 line is now in &quot;security only&quot; mode).<br><br>Eli<br><br></div>

From report at bugs.python.org  Sat Jul 16 17:10:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 15:10:41 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <CAPZV6o8SqYkBfspQ+QhsNmtVo5rqFVGCKDQkaYcM_25sc9cC9A@mail.gmail.com>
Message-ID: <CADiSq7epzpEjafveK447zjdv1Qm+ZFghYCUR06r22q5EVyL=pA@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's important to remember that other implementations treat CPython as
the "gold standard" for compatibility purposes. If we declare
something to be an ordinary SyntaxError, then that carries strong
implications for what other implementations should do.

Some kinds of errors are inherently implementation specific
(MemoryError and SystemError spring to mind). No sane implementor is
going to try to match CPython like-for-like when it comes to those.
SyntaxError, however, is typically defined by the language definition,
not the CPython implementation of it. By introducing a new exception
type, we're explicitly telling other implementations "Look, this is
our problem that we don't plan to fix as it doesn't typically arise in
real code, but please don't deliberately cripple your own
implementation just to match this behaviour". I'm strongly with MvL on
this one - SyntaxError itself should never be raised for legal Python
code just because the CPython bytecode generation toolchain isn't able
to handle it properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 17:16:05 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jul 2011 15:16:05 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <CADiSq7epzpEjafveK447zjdv1Qm+ZFghYCUR06r22q5EVyL=pA@mail.gmail.com>
Message-ID: <CAPZV6o_pXJgh2ZJ8UVkbC=M+W2R6FgXJr+BoRGw3HDFyrpO5jA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/16 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> It's important to remember that other implementations treat CPython as
> the "gold standard" for compatibility purposes. If we declare
> something to be an ordinary SyntaxError, then that carries strong
> implications for what other implementations should do.
>
> Some kinds of errors are inherently implementation specific
> (MemoryError and SystemError spring to mind). No sane implementor is
> going to try to match CPython like-for-like when it comes to those.
> SyntaxError, however, is typically defined by the language definition,
> not the CPython implementation of it. By introducing a new exception
> type, we're explicitly telling other implementations "Look, this is
> our problem that we don't plan to fix as it doesn't typically arise in
> real code, but please don't deliberately cripple your own
> implementation just to match this behaviour". I'm strongly with MvL on
> this one - SyntaxError itself should never be raised for legal Python
> code just because the CPython bytecode generation toolchain isn't able
> to handle it properly.

Implementations are quite good at figuring this stuff out themselves.
We don't need a whole new exception (new docs, one more thing in the
builtin namespace) to "send a message" to other implementations. If
some implementation is not part of the language, then its test just
just be marked cpython_only. It shouldn't be brought into public API
and the language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 17:22:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 15:22:46 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <CAPZV6o_pXJgh2ZJ8UVkbC=M+W2R6FgXJr+BoRGw3HDFyrpO5jA@mail.gmail.com>
Message-ID: <CADiSq7dUEAJO=dSGFxWSHtNp2AXrO_VFuec+Ns_yi4dCVNuBiw@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It also makes it clear to users whether they've just run up against a
limitation of the implementation they're using or whether what they've
written is genuinely illegal code. They are NOT the same thing.
Attempting to conflate them into one exception for the mere sake of
not adding a new exception type is a false economy. Take it to
python-dev if you want, but I will strongly oppose this check going in
with it raising an ordinary SyntaxError instead of a new subclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 17:33:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jul 2011 15:33:26 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <CADiSq7dUEAJO=dSGFxWSHtNp2AXrO_VFuec+Ns_yi4dCVNuBiw@mail.gmail.com>
Message-ID: <CAPZV6o-zuA+TyX=Hi07hNY2+joRZ0op+0Pyz07R58uQyNFcotA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/16 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> It also makes it clear to users whether they've just run up against a
> limitation of the implementation they're using or whether what they've
> written is genuinely illegal code. They are NOT the same thing.
> Attempting to conflate them into one exception for the mere sake of
> not adding a new exception type is a false economy. Take it to
> python-dev if you want, but I will strongly oppose this check going in
> with it raising an ordinary SyntaxError instead of a new subclass.

Why would it matter to users what variety of limitation they're
running up against? As I said, they're still going to have to change
their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 17:52:27 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 16 Jul 2011 15:52:27 +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: <1310831547.58.0.431931731101.issue11343@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/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 17:53:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Jul 2011 15:53:45 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <CAPZV6o-zuA+TyX=Hi07hNY2+joRZ0op+0Pyz07R58uQyNFcotA@mail.gmail.com>
Message-ID: <CADiSq7eEiezxdopoS2D2pvRps=dkLNjpKN4E7V_7PbUG-ZjtKg@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It matters, because Python "users" are programmers, and most
programmers want to know *why* they're being told something is wrong.
Raising MemoryError is technically incorrect at this point, but at
least gives the right flavour of the user not doing anything
specifically wrong, the program just ran out of resources trying to do
as they asked. I see SyntaxError as significantly worse, however, as
instead of telling the developer "sorry, that's a reasonable request,
but I can't handle it", the interpreter is now telling them "you did
that wrong, change it". The semantics of that are all wrong. There's
nothing wrong with the syntax of the user's code, it's just that the
compiler can't handle it.

Similarly, the eventual fix to the recursive crash in the compiler
itself is likely to be an arbitrary limit on expression nesting.
Again, nothing wrong with their syntax, but they'll need to adjust
their (legal!) code to work around implementation limitations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 18:08:00 2011
From: report at bugs.python.org (Rafe Kettler)
Date: Sat, 16 Jul 2011 16:08:00 +0000
Subject: [issue12574] Documentation for Queue in 2.x has an incorrect title
In-Reply-To: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>
Message-ID: <1310832480.85.0.955321578744.issue12574@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

Okay, here's a patch.

I also went ahead and added my name to ACKS, since this is my 3rd or 4th patch.

Rafe

----------
keywords: +patch
Added file: http://bugs.python.org/file22677/queue_docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12574>
_______________________________________

From report at bugs.python.org  Sat Jul 16 18:50:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jul 2011 16:50:35 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <CADiSq7eEiezxdopoS2D2pvRps=dkLNjpKN4E7V_7PbUG-ZjtKg@mail.gmail.com>
Message-ID: <CAPZV6o9hB_R4OR2EL9kpMmtnQr_q2TsUs5zA-tR6sAtfUtJBYA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/16 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> It matters, because Python "users" are programmers, and most
> programmers want to know *why* they're being told something is wrong.
> Raising MemoryError is technically incorrect at this point, but at
> least gives the right flavour of the user not doing anything
> specifically wrong, the program just ran out of resources trying to do
> as they asked. I see SyntaxError as significantly worse, however, as
> instead of telling the developer "sorry, that's a reasonable request,
> but I can't handle it", the interpreter is now telling them "you did
> that wrong, change it". The semantics of that are all wrong. There's
> nothing wrong with the syntax of the user's code, it's just that the
> compiler can't handle it.

I content that in normal code, it is so extremely rare as to be
unheard of, to get exceptions about the parser stack overflowing or
segfault the compiler by too deep nesting. People who are doing this
(generally to prove the point about limitations of the compiler) are
smart enough to know exactly what "parser stack overflowed" means and
separate that from Python as the language. Adding a new exception is
solving a non-existent problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Jul 16 19:10:09 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Jul 2011 17:10:09 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

The goal of this patch to keep people doing silly things like producing a Try with no finalbody or excepthandlers and segfaulting the compiler in unpleasant ways.

----------
components: Interpreter Core
files: ast_validator.patch
keywords: patch
messages: 140505
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: add a AST validator
versions: Python 3.3
Added file: http://bugs.python.org/file22678/ast_validator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Sun Jul 17 00:21:16 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 16 Jul 2011 22:21:16 +0000
Subject: [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1310854876.2.0.488162335181.issue7620@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/issue7620>
_______________________________________

From report at bugs.python.org  Sun Jul 17 00:27:13 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 16 Jul 2011 22:27:13 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
	files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1310855233.37.0.642426877076.issue8912@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/issue8912>
_______________________________________

From report at bugs.python.org  Sun Jul 17 00:28:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jul 2011 22:28:55 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <CAPZV6o9hB_R4OR2EL9kpMmtnQr_q2TsUs5zA-tR6sAtfUtJBYA@mail.gmail.com>
Message-ID: <1310855265.3630.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I content that in normal code, it is so extremely rare as to be
> unheard of, to get exceptions about the parser stack overflowing or
> segfault the compiler by too deep nesting. People who are doing this
> (generally to prove the point about limitations of the compiler) are
> smart enough to know exactly what "parser stack overflowed" means and
> separate that from Python as the language. Adding a new exception is
> solving a non-existent problem.

Agreed with Benjamin. Also, "why something is wrong" can simply be told
in the exception message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sun Jul 17 01:13:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Jul 2011 23:13:20 +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: <1310858000.54.0.704922570905.issue11343@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a purity versus practicality argument.  I agree with both sides :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sun Jul 17 01:27:34 2011
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Sat, 16 Jul 2011 23:27:34 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1310858854.96.0.355665183993.issue12133@psf.upfronthosting.co.za>


Ugra D?niel <daniel.ugra at gmail.com> added the comment:

This patch has introduced some problems for me with Python 3.2.1 (64-bit Arch Linux).

The following code:

with urllib.request.urlopen(url) as page:
    pass

raises "ValueError: I/O operation on closed file." exception when url is "http://www.imdb.com/".

When I removed "h.close()" (added by this patch) from request.py everything worked as expected.

Interestingly other URLs work flawlessly with patched code ("http://www.google.com/" for example).

I had no time to further investigate the differences between HTTP responses of "good" and "bad" sites... and I am by no means an HTTP expert :)

Should I open a new bug report for this one or is it OK to just leave this comment here?

----------
nosy: +daniel.ugra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Sun Jul 17 01:29:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Jul 2011 23:29:37 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1310858977.52.0.721545745573.issue12133@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Should I open a new bug report for this one or is it OK to just leave
> this comment here?

I think it's better to open a new issue, thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Sun Jul 17 01:41:06 2011
From: report at bugs.python.org (Armin Ronacher)
Date: Sat, 16 Jul 2011 23:41:06 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1310859666.04.0.412543469233.issue12575@psf.upfronthosting.co.za>


Armin Ronacher <armin.ronacher at active-4.com> added the comment:

I see what you did there :P

----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Sun Jul 17 01:42:53 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 16 Jul 2011 23:42:53 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1310859773.04.0.0533606119343.issue12575@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Sun Jul 17 01:58:07 2011
From: report at bugs.python.org (Eric)
Date: Sat, 16 Jul 2011 23:58:07 +0000
Subject: [issue7474] multiprocessing.managers.SyncManager managed object
	creation fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1310860687.28.0.955847228773.issue7474@psf.upfronthosting.co.za>


Eric <etzool at hotmail.com> added the comment:

Tested in 2.6.6 on Gentoo and 2.7.1 on Ubuntu (Server); this behavior is no longer present when using the provided code.

Hopefully this means the original issue has been solved; I haven't touched the code that revealed it since around the time I filed this originally.

If someone can confirm that the test code works in whatever versions of Python 3 are current, please go ahead and close this.

----------
status: open -> pending
versions: +Python 2.6 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7474>
_______________________________________

From report at bugs.python.org  Sun Jul 17 01:58:33 2011
From: report at bugs.python.org (Eric)
Date: Sat, 16 Jul 2011 23:58:33 +0000
Subject: [issue7474] multiprocessing.managers.SyncManager managed object
	creation fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1310860713.36.0.330937627814.issue7474@psf.upfronthosting.co.za>


Changes by Eric <etzool at hotmail.com>:


----------
status: pending -> open
versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7474>
_______________________________________

From report at bugs.python.org  Sun Jul 17 02:07:44 2011
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Sun, 17 Jul 2011 00:07:44 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>


New submission from Ugra D?niel <daniel.ugra at gmail.com>:

Issue #12133 introduced a patch which seems to cause problems.
I'm using Python 3.2.1 on 64-bit Arch Linux (this version already incorporates the changes from #12133).

The following code:

with urllib.request.urlopen(url) as page:
    pass

raises "ValueError: I/O operation on closed file." exception when url is "http://www.imdb.com/".
When I removed "h.close()" (added by the patch) from request.py everything worked as expected.
Other URLs work flawlessly with patched code ("http://www.google.com/" for example).

Maybe it is something to do with differences in HTTP responses or in server-side behavior.
For example IMDb's "Cneonction: close" (not a typo) feature.
But this could be totally unrelated, I am by no means an HTTP expert.

----------
components: Library (Lib)
messages: 140512
nosy: daniel.ugra
priority: normal
severity: normal
status: open
title: urlib.request fails to open some sites
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sun Jul 17 03:29:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jul 2011 01:29:26 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <20110717012918.GC2879@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Sun, Jul 17, 2011 at 12:07:44AM +0000, Ugra D?niel wrote:

> For example IMDb's "Cneonction: close" (not a typo) feature.  But

This is a mistake at the server and urllib relies on the
Connection: close header at some point in time in the process.

You could try with few other sites and see that context manager should
work.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sun Jul 17 04:53:46 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 Jul 2011 02:53:46 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310859666.04.0.412543469233.issue12575@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o8aqhEtNYpr1GBf1kc0uvkqQK_YgiRdp8pd3XZeKCV6CQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/16 Armin Ronacher <report at bugs.python.org>:
>
> Armin Ronacher <armin.ronacher at active-4.com> added the comment:
>
> I see what you did there :P

Is that a message of approval? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Sun Jul 17 04:54:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jul 2011 02:54:53 +0000
Subject: [issue12574] Documentation for Queue in 2.x has an incorrect title
In-Reply-To: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>
Message-ID: <E1QiHVM-0005fG-2I@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 60ce5f279a5e by Eli Bendersky in branch '2.7':
Issue #12574: correct capitalization of the Queue module. Patch by Rafe Kettler
http://hg.python.org/cpython/rev/60ce5f279a5e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12574>
_______________________________________

From report at bugs.python.org  Sun Jul 17 04:56:59 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 17 Jul 2011 02:56:59 +0000
Subject: [issue12574] Documentation for Queue in 2.x has an incorrect title
In-Reply-To: <1310772348.87.0.605438364285.issue12574@psf.upfronthosting.co.za>
Message-ID: <1310871419.43.0.871247981082.issue12574@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12574>
_______________________________________

From senthil at uthcode.com  Sun Jul 17 07:04:06 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 17 Jul 2011 13:04:06 +0800
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1310568635.67.0.452425332232.issue1170@psf.upfronthosting.co.za>
References: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
	<1310568635.67.0.452425332232.issue1170@psf.upfronthosting.co.za>
Message-ID: <20110717050406.GF2879@mathmagic>

TypeError should be okay. But I am still -0 on that. It would be good
to hear a strong argument from the user that how did he end up passing
unicode to shlex.split? It is for parsing command line args for
programs and personally have not seen those cases. Or did he want
unicode everywhere if we was using just using ascii characters.

From report at bugs.python.org  Sun Jul 17 07:04:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jul 2011 05:04:13 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1310568635.67.0.452425332232.issue1170@psf.upfronthosting.co.za>
Message-ID: <20110717050406.GF2879@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

TypeError should be okay. But I am still -0 on that. It would be good
to hear a strong argument from the user that how did he end up passing
unicode to shlex.split? It is for parsing command line args for
programs and personally have not seen those cases. Or did he want
unicode everywhere if we was using just using ascii characters.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sun Jul 17 08:06:09 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 17 Jul 2011 06:06:09 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1310882769.74.0.0499444343626.issue12575@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/issue12575>
_______________________________________

From report at bugs.python.org  Sun Jul 17 08:32:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Jul 2011 06:32:24 +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: <1310884344.88.0.202316551835.issue11343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

After further reflection, I (eventually) came to the same conclusion as Benjamin and Antoine - using SyntaxError for this is fine.

However, the exception *message* should make it clear that this is an implementation limit rather than a language limit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sun Jul 17 08:50:55 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 17 Jul 2011 06:50:55 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310885455.24.0.693336024561.issue12576@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sun Jul 17 09:51:40 2011
From: report at bugs.python.org (Santiago Romero)
Date: Sun, 17 Jul 2011 07:51:40 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310889100.22.0.629496498429.issue1170@psf.upfronthosting.co.za>


Santiago Romero <sromero at gmail.com> added the comment:

> It would be good to hear a strong argument from
> the user that how did he end up passing
> unicode to shlex.split? It is for parsing command
> line args for programs and personally have not
> seen those cases.

 I'm from Spain: I personally write programs and python/bash scripts that accept unicode input arguments. And I'm currently writing a wxpython gui program (SSH/rdesktop launcher, in Spanish) that needs (and cannot) do shlex.split in of a given text string.

 Remember that English is NOT the most spoken language on the world. It's the THIRD most spoken language, after Chinese and Spanish, languages that need and use unicode support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sun Jul 17 10:33:42 2011
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 17 Jul 2011 08:33:42 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310891622.62.0.69078734459.issue1170@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy:  -cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sun Jul 17 10:54:27 2011
From: report at bugs.python.org (anand jeyahar)
Date: Sun, 17 Jul 2011 08:54:27 +0000
Subject: [issue12381] refactor slice checks made by methods that take "slice
	like" arguments
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1310892867.18.0.477059302017.issue12381@psf.upfronthosting.co.za>


anand jeyahar <anand.jeyahar at gmail.com> added the comment:

I started working on this. But found sliceobject.c. Think it would be a good idea to add the refactored functions there. Anyway, i was trying to figure out the functionality of sliceobject.c. Can someone put up a use/test case example for it? Thanks for patience with my newbieness to python source

----------
nosy: +anand.jeyahar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12381>
_______________________________________

From report at bugs.python.org  Sun Jul 17 10:59:21 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 17 Jul 2011 08:59:21 +0000
Subject: [issue12577] Misleading shutil.move docs regarding when os.rename is
	used
In-Reply-To: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>
Message-ID: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>


New submission from Catalin Iacob <iacobcatalin at gmail.com>:

I recently tried to answer the question: "When moving a file to a destination that is an already existing file, is the destination overwritten?"

>From the current docs I understood that if src and dst are on the same filesystem then os.rename is used, if they are on different filesystems then copy + remove is used instead. Since os.rename fails on Windows if the destination exists I concluded that shutil.move would fail on Windows and overwrite dst on Unix.

----------
assignee: docs at python
components: Documentation
messages: 140520
nosy: catalin.iacob, docs at python
priority: normal
severity: normal
status: open
title: Misleading shutil.move docs regarding when os.rename is used
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12577>
_______________________________________

From report at bugs.python.org  Sun Jul 17 11:00:14 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 17 Jul 2011 09:00:14 +0000
Subject: [issue12577] Misleading shutil.move docs regarding when os.rename is
	used
In-Reply-To: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>
Message-ID: <1310893214.16.0.939010185663.issue12577@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Attached patch which clarifies that the copy fallback is used whenever os.rename fails not just for the different filesystems case.

----------
keywords: +patch
Added file: http://bugs.python.org/file22679/clarify-shutil.move-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12577>
_______________________________________

From report at bugs.python.org  Sun Jul 17 11:32:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jul 2011 09:32:25 +0000
Subject: [issue11436] Clarify struct doc for format 's',
	when it is mentioned without numeric prefix
In-Reply-To: <1299522578.2.0.51699411527.issue11436@psf.upfronthosting.co.za>
Message-ID: <E1QiNi3-00035h-Gn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 90cdf403132e by Senthil Kumaran in branch '3.2':
Fix closes Issue11436 - Minor clarification to struct documentation for 's' format character.
http://hg.python.org/cpython/rev/90cdf403132e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11436>
_______________________________________

From report at bugs.python.org  Sun Jul 17 13:06:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jul 2011 11:06:20 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <E1QiPAw-0000xH-G4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 05f0ffe4e0b3 by Senthil Kumaran in branch '3.2':
Fix Issue10403 - datetime documentation clarification based on review in the reitveld by Alexendar belopolsky.
http://hg.python.org/cpython/rev/05f0ffe4e0b3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Sun Jul 17 13:10:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jul 2011 11:10:32 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <E1QiPF1-0001Dc-3g@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3935a1fb1db2 by Senthil Kumaran in branch '2.7':
merge from 3.2 - Issue10403  - datetime module documentation changes based on review.
http://hg.python.org/cpython/rev/3935a1fb1db2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Sun Jul 17 13:11:10 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jul 2011 11:11:10 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1310901070.83.0.286202253329.issue10403@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Sun Jul 17 13:39:39 2011
From: report at bugs.python.org (David Ward)
Date: Sun, 17 Jul 2011 11:39:39 +0000
Subject: [issue12578] Erratic socket.gaierror: [Errno 11004] when using smtplib
In-Reply-To: <1310902779.89.0.705938348131.issue12578@psf.upfronthosting.co.za>
Message-ID: <1310902779.89.0.705938348131.issue12578@psf.upfronthosting.co.za>


New submission from David Ward <d.j.ward.94 at gmail.com>:

When migrating from python 2.7.1 to 2.7.2 (or 3.2) I get unpredictable /erratic exceptions thrown on constucting smtplib.SMTP:

socket.gaierror: [Errno 11004] getaddrinfo failed 

Here is the call stack:

  File "**********\mail.py", line 41, in Mail
    server = smtplib.SMTP(MAILSERVER)
  File "c:\python27\lib\smtplib.py", line 250, in __init__
    (code, msg) = self.connect(host, port)
  File "c:\python27\lib\smtplib.py", line 306, in connect
    self.sock = self._get_socket(host, port, self.timeout)
  File "c:\python27\lib\smtplib.py", line 284, in _get_socket
    return socket.create_connection((host, port), timeout)
  File "c:\python27\lib\socket.py", line 380, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno 11004] getaddrinfo failed

MAILSERVER is a local address. There are no known DNS issues on our local network. 

If I try to reduce the code to a small repro (e.g. sending mail in a loop or calling getaddrinfo), I cannot reproduce the problem.

This code had worked unchanged for many years and many previous python releases all the way back to 2.3.

Platform is Windows 7 x64, AMD64 build of python 2.7.2 (or 3.2).

Reverting back to 2.7.1 solves the problem.

----------
components: Library (Lib)
messages: 140525
nosy: David.Ward
priority: normal
severity: normal
status: open
title: Erratic socket.gaierror: [Errno 11004] when using smtplib
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12578>
_______________________________________

From report at bugs.python.org  Sun Jul 17 14:05:31 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 17 Jul 2011 12:05:31 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1310904331.92.0.687885742559.issue12575@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/issue12575>
_______________________________________

From report at bugs.python.org  Sun Jul 17 14:47:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jul 2011 12:47:34 +0000
Subject: [issue12578] Erratic socket.gaierror: [Errno 11004] when using smtplib
In-Reply-To: <1310902779.89.0.705938348131.issue12578@psf.upfronthosting.co.za>
Message-ID: <1310906854.54.0.480541424176.issue12578@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This sounds rather strange. There haven't been any significant changes in smtplib or the socket module between 2.7.1 and 2.7.2.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12578>
_______________________________________

From report at bugs.python.org  Sun Jul 17 14:56:03 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 17 Jul 2011 12:56:03 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1310907363.18.0.327801705853.issue7484@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

I looked at the Felipe's patch and hopefully made some improvements.

Unlike Felipe's patch I didn't change the reply of the SMTP server in the tests but instead use what VRFY and EXPN actually send to index the users and lists dictionaries. If <> would be sent the lookup would fail. Similarly, when VRFY return 550 it echoed the address as received and now it's tested to be equal to something without <>.

By the way, but I was wondering:
* is the try/except really needed or just a historical artifact (why would email.utils.parseaddr raise AttributeError?)
* is the test to None correct? It was added by the fix to issue1430298 but does email.utils.parseaddr ever return None for the address? (I could only get it to return '')
I kept quoteaddr as is to make it easier to review the patch but if David confirms the above points are valid I can create new issues for them and simplify/fix quoteaddr.

----------
hgrepos: +43

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Sun Jul 17 14:57:16 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 17 Jul 2011 12:57:16 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1310907436.66.0.390392007252.issue7484@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


Added file: http://bugs.python.org/file22680/88b5c7ab7a03.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Sun Jul 17 16:43:42 2011
From: report at bugs.python.org (Julian)
Date: Sun, 17 Jul 2011 14:43:42 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>


New submission from Julian <Julian+Python.org at GrayVines.com>:

Attached is just a failing test case (just `print("{}".format_map(12))`), haven't been able to decipher the chain of calls in the unicodeobject.c code yet to see where the best place to put the fix would be (inside do_format_map before the pass back upwards maybe?).

Assuming this should be a TypeError obviously, soon as I can figure out where to put the fix I'll update the patch.

----------
components: Interpreter Core
files: format_map_err.patch
keywords: patch
messages: 140528
nosy: Julian
priority: normal
severity: normal
status: open
title: str.format_map raises a SystemError for non-mapping
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22681/format_map_err.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Sun Jul 17 16:54:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Jul 2011 14:54:39 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310914479.15.0.800375795986.issue12579@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Sun Jul 17 17:59:37 2011
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 17 Jul 2011 15:59:37 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310918377.89.0.517855536135.issue1170@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Right. Any program that needs to parse command lines containing filenames or other arguments with unicode characters will encounter this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Sun Jul 17 19:49:18 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Jul 2011 17:49:18 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310924958.38.0.914850129212.issue12579@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Sun Jul 17 19:53:05 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Jul 2011 17:53:05 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310925185.63.0.860787816118.issue12579@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

If you want to look at this, I think there's a missing check for args being non-null in string_format.h, line 515.

I'd have to think to see if there are other possible failure scenarios.

Thanks for the report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Sun Jul 17 20:30:02 2011
From: report at bugs.python.org (Steve Holden)
Date: Sun, 17 Jul 2011 18:30:02 +0000
Subject: [issue12580] Documentation error in Decimal module
In-Reply-To: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>
Message-ID: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>


New submission from Steve Holden <steve at holdenweb.com>:

We see in the "Quick-Start Tutorial" (py3k section 8.4.1) the following example:

>>> Decimal(3.14)
Decimal('3.140000000000000124344978758017532527446746826171875')

In actua; fact one would expect an exception from that code, which should perhaps instead read

>>> Decimal.from_float(3.14)
Decimal('3.140000000000000124344978758017532527446746826171875')

This class method is the recommended way to convert floats to decimal when necessary.

----------
assignee: georg.brandl
messages: 140531
nosy: georg.brandl, holdenweb
priority: normal
severity: normal
status: open
title: Documentation error in Decimal module
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12580>
_______________________________________

From report at bugs.python.org  Sun Jul 17 20:30:46 2011
From: report at bugs.python.org (Steve Holden)
Date: Sun, 17 Jul 2011 18:30:46 +0000
Subject: [issue12580] Documentation error in Decimal module
In-Reply-To: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>
Message-ID: <1310927446.93.0.497507848414.issue12580@psf.upfronthosting.co.za>


Changes by Steve Holden <steve at holdenweb.com>:


----------
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12580>
_______________________________________

From report at bugs.python.org  Sun Jul 17 20:50:57 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Jul 2011 18:50:57 +0000
Subject: [issue12580] Documentation error in Decimal module
In-Reply-To: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>
Message-ID: <1310928657.78.0.763405959053.issue12580@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Behavior for mixed operations varies greatly between Python versions.

The first table over here lists the differences and should be valid
for decimal.py:

http://www.bytereef.org/mpdecimal/doc/cdecimal/index.html#floatoperation-signal


As an extension, cdecimal has the FloatOperation signal, which
enforces stricter semantics. The second table on that page lists
the behavior if the signal is enabled.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12580>
_______________________________________

From report at bugs.python.org  Sun Jul 17 21:04:43 2011
From: report at bugs.python.org (Andrew Dalke)
Date: Sun, 17 Jul 2011 19:04:43 +0000
Subject: [issue1602133] non-framework built python fails to define environ
	properly
Message-ID: <1310929483.99.0.115369861146.issue1602133@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

I confirm that under Python 2.7.2 while trying to build a 3rd-party package (from rdkit.org) I get the error


Linking CXX shared library ../../lib/libRDBoost.dylib
ld: warning: path '/usr/local/lib/libpython2.7.a' following -L not a directory
Undefined symbols:
  "_environ", referenced from:
      _initposix in libpython2.7.a(posixmodule.o)
     (maybe you meant: cstring=ignore_environment)
ld: symbol(s) not found
collect2: ld returned 1 exit status

My Python-2.7 was configured with "./configure" and is not a framework install. I applied the patch to my local 2.7 copy and the third party package builds without a problem.

----------
nosy: +dalke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602133>
_______________________________________

From report at bugs.python.org  Sun Jul 17 21:04:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Jul 2011 19:04:53 +0000
Subject: [issue12580] Documentation error in Decimal module
In-Reply-To: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>
Message-ID: <1310929493.05.0.118361621295.issue12580@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12580>
_______________________________________

From report at bugs.python.org  Sun Jul 17 21:07:13 2011
From: report at bugs.python.org (Nir Soffer)
Date: Sun, 17 Jul 2011 19:07:13 +0000
Subject: [issue4277] asynchat's handle_error inconsistency
In-Reply-To: <1226060153.34.0.769481825348.issue4277@psf.upfronthosting.co.za>
Message-ID: <1310929633.21.0.209965242152.issue4277@psf.upfronthosting.co.za>


Nir Soffer <nirsof at gmail.com> added the comment:

The idea is good, but seems that error handling should be inlined into initiate_send.

Also those 3 special exceptions should be defined once in the module instead of repeating them.

----------
nosy: +nirs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4277>
_______________________________________

From report at bugs.python.org  Sun Jul 17 21:07:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Jul 2011 19:07:50 +0000
Subject: [issue12580] Documentation error in Decimal module
In-Reply-To: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>
Message-ID: <1310929670.72.0.668489756327.issue12580@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The example is correct and runs as expected:

>>> Decimal(3.14)
Decimal('3.140000000000000124344978758017532527446746826171875')

Per the Whatsnew3.2 document:
'''
The decimal.Decimal constructor now accepts float objects directly so there in no longer a need to use the from_float() method (issue 8257).
'''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12580>
_______________________________________

From report at bugs.python.org  Sun Jul 17 21:23:09 2011
From: report at bugs.python.org (Steve Holden)
Date: Sun, 17 Jul 2011 19:23:09 +0000
Subject: [issue12580] Documentation error in Decimal module
In-Reply-To: <1310927402.36.0.418806971374.issue12580@psf.upfronthosting.co.za>
Message-ID: <1310930589.76.0.30070851629.issue12580@psf.upfronthosting.co.za>


Steve Holden <steve at holdenweb.com> added the comment:

Sorry about that. I was using 3.1, as you will have gathered.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12580>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:00:23 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Jul 2011 22:00:23 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310940023.65.0.0734439361391.issue12579@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Actually that's probably not the place to catch it. Let me look at it closer. Of course, patches welcome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:05:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jul 2011 22:05:12 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1310940312.31.0.473185442402.issue11468@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I would be +1 if the basic example also highlights setUp and tearDown methods. Those are useful ones for a new comer to know via an example snippet and not just with explanation.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:11:49 2011
From: report at bugs.python.org (Julian)
Date: Sun, 17 Jul 2011 22:11:49 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310940709.1.0.888454553453.issue12579@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

Yeah, I saw the line you suggested and didn't think that was it.

To expand on this, perhaps "{foo}".format(12) should raise a TypeError as well? I'd expect that more than the current behavior which is a KeyError. That KeyError is getting raised in get_field_object, which is where the fix needs to be, or at least needs to be changed, I'm just trying not to duplicate code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:12:58 2011
From: report at bugs.python.org (Julian)
Date: Sun, 17 Jul 2011 22:12:58 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310940778.8.0.620200773393.issue12579@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

Sorry for the double post, meant to say, in line 506.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:20:38 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Jul 2011 22:20:38 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310941238.17.0.721712927077.issue12579@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I think KeyError for "{foo}".format(12) is correct. It's looking up "foo" in the empty dict of **kwargs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:23:45 2011
From: report at bugs.python.org (Julian)
Date: Sun, 17 Jul 2011 22:23:45 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310941425.3.0.839980943296.issue12579@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

Fair enough. I suppose I take .format_map to mean, here is a mapping, call __getitem__ on it for each of the keys inside the format string, to which calling 12["foo"] would get me a TypeError.

I suppose I see both as appropriate, but the fact that it's implemented by passing the mapping as kwargs seemed less relevant. Less concerned about that part though I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:33:49 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jul 2011 22:33:49 +0000
Subject: [issue12577] Misleading shutil.move docs regarding when os.rename is
	used
In-Reply-To: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>
Message-ID: <1310942029.52.0.0641175790476.issue12577@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Should information on Windows behavior, which you experienced be included too?

How about - 

It uses :func:`os.rename` to perform the move. If that fails, for example
because src and dst are on different filesystems or in case of Windows where rename cannot be done if dst exists, fallback to copying src (with :func:`copy2`) to the dst and then removing src.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12577>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:38:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Jul 2011 22:38:26 +0000
Subject: [issue12441] _GLOBAL_DEFAULT_TIMEOUT remains as an object() in
	HTTPConnection and the connection hangs
In-Reply-To: <1309346319.84.0.970353674809.issue12441@psf.upfronthosting.co.za>
Message-ID: <1310942306.01.0.660313500359.issue12441@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Would you like to give an example snippet (server+client) which can help reproduce this behavior?

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12441>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:44:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jul 2011 22:44:38 +0000
Subject: [issue12479] Add HTTPErrorProcessor class definition
In-Reply-To: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>
Message-ID: <E1Qia4j-0002QI-9p@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8d64d47569cb by Senthil Kumaran in branch '3.2':
Fix closes Issue12479 - Add HTTPErrorProcessor class definition - Patch by Sandro Tosi
http://hg.python.org/cpython/rev/8d64d47569cb

New changeset b2125a6deb96 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes Issue12479 - Add HTTPErrorProcessor class definition - Patch by Sandro Tosi
http://hg.python.org/cpython/rev/b2125a6deb96

New changeset b9ae6be1874d by Senthil Kumaran in branch '2.7':
merge from 3.2 - Fix closes Issue12479 - Add HTTPErrorProcessor class definition - Patch by Sandro Tosi
http://hg.python.org/cpython/rev/b9ae6be1874d

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12479>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:44:38 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Jul 2011 22:44:38 +0000
Subject: [issue12579] str.format_map raises a SystemError for non-mapping
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310942678.95.0.424167102663.issue12579@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I think the issue is that it should be an error in any string used for format_map() to have a positional argument. So the right thing to do is detect this case in get_field_object (index != -1 and args is NULL). So I think a new test near line 515 really is the right thing to do. With a good comment explaining what's going on.

I'm pretty sure the only case where args is NULL is when used with format_map(), but that needs to be verified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 00:46:19 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Jul 2011 22:46:19 +0000
Subject: [issue12579] str.format_map raises a SystemError for format strings
	with positional arguments
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310942779.55.0.203240671498.issue12579@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Changing the title to reflect the real problem.

You get a SystemError even when using a mapping, if you have a format string with positional arguments:
>>> '{}'.format_map({'a':0})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: null argument to internal routine

----------
title: str.format_map raises a SystemError for non-mapping -> str.format_map raises a SystemError for format strings with positional arguments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 01:19:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jul 2011 23:19:12 +0000
Subject: [issue12478] Possible error in HTTPErrorProcessor documentation
In-Reply-To: <1309695268.0.0.0456155108685.issue12478@psf.upfronthosting.co.za>
Message-ID: <E1QiacA-0004VK-Sh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 70983e8b114a by Senthil Kumaran in branch '3.2':
Fix closes Issue12478 - HTTPErrorProcess 's methods are http_response and https_response.
http://hg.python.org/cpython/rev/70983e8b114a

New changeset 04541e33364d by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes Issue12478 - HTTPErrorProcess 's methods are http_response and https_response.
http://hg.python.org/cpython/rev/04541e33364d

New changeset edf238312baa by Senthil Kumaran in branch '2.7':
merge from 3.2 - Fix closes Issue12478 - HTTPErrorProcess 's methods are http_response and https_response.
http://hg.python.org/cpython/rev/edf238312baa

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12478>
_______________________________________

From report at bugs.python.org  Mon Jul 18 02:17:14 2011
From: report at bugs.python.org (Julian)
Date: Mon, 18 Jul 2011 00:17:14 +0000
Subject: [issue12579] str.format_map raises a SystemError for format strings
	with positional arguments
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310948234.45.0.760003591759.issue12579@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

Well you're right :). I appreciate you taking more time to help me with this than you could have yourself. I made the change (and changed the TypeError to a ValueError as per your discovery that this was just a positional value issue, hope you agree with that).

Ran the whole test suite, all passes, other than the one test that fails for me without the patch too.

I'm not too happy with the wording on the error, "Format string contained positional fields" doesn't sound nearly specific enough, but I was weary to put something specifically referencing str.format_map in a function that handles str.format as well?

Anyways, appreciate the help again, please let me know if anything needs fixing :).

----------
Added file: http://bugs.python.org/file22682/format_map_err.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 02:27:23 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Jul 2011 00:27:23 +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: <1310948843.54.0.948576902908.issue6721@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

No Python thread is ever fork safe because the Python interpreter itself can never be made fork safe. Nor should anyone try to make the interpreter itself safe. It is too complex and effectively impossible to guarantee.

There is no general solution to this, fork and threading is simply broken in POSIX and no amount of duct tape outside of the OS kernel can fix it. My only desire is that we attempt to do the right thing when possible with the locks we know about within the standard library.

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Mon Jul 18 02:53:31 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 18 Jul 2011 00:53:31 +0000
Subject: [issue12579] str.format_map raises a SystemError for format strings
	with positional arguments
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310950411.85.0.304719726344.issue12579@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I definitely agree it should be a ValueError.

How about including in your patch adding your name to Misc/ACKS, if it isn't already there? I don't have your full name.

I might play with the exception wording and add a few more comments. Thanks for your work on this.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 02:56:46 2011
From: report at bugs.python.org (Jeff Blaine)
Date: Mon, 18 Jul 2011 00:56:46 +0000
Subject: [issue12013] file
	/usr/local/lib/python3.1/lib-dynload/_socket.so:	symbol
	inet_aton: referenced symbol not found
In-Reply-To: <1304644585.52.0.347221630935.issue12013@psf.upfronthosting.co.za>
Message-ID: <1310950606.26.0.619981641442.issue12013@psf.upfronthosting.co.za>


Jeff Blaine <cjblaine at gmail.com> added the comment:

FWIW, this same problem exists with 2.7.1, compiled by myself, and only on some Solaris 10 boxes of ours that have not had a lot of recent patching.

==================================================================

On an old-ish Solaris 10 box:

% /tmp/py271test/bin/python -m test.regrtest
Traceback (most recent call last):
  File "/tmp/py271test/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/tmp/py271test/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/tmp/py271test/lib/python2.7/test/regrtest.py", line 211, in <module>
    from test import test_support
  File "/tmp/py271test/lib/python2.7/test/test_support.py", line 10, in <module>
    import socket
  File "/tmp/py271test/lib/python2.7/socket.py", line 47, in <module>
    import _socket
ImportError: ld.so.1: python: fatal: relocation error: file /tmp/py271test/lib/python2.7/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found
==================================================================

On a modern Solaris 10 box patched 2 months ago:


% /tmp/py271test/bin/python -m test.regrtest
[ runs, takes too long, so we'll test the stuff that ]
[ imports socket ... ]
^C


Python-2.7.1:cairo> for i in `grep -l "import socket" /tmp/py271test/lib/python
2.7/test/*py | sed 's/\.py//g'`; do echo "RUNNING $i"; /tmp/py271test/bin/pytho
n -m test.`basename $i`; done 2>&1 | /usr/sfw/bin/ggrep -E '(OK|RUNNING)'
RUNNING /tmp/py271test/lib/python2.7/test/test_asyncore
OK (skipped=2)
RUNNING /tmp/py271test/lib/python2.7/test/test_docxmlrpc
OK
RUNNING /tmp/py271test/lib/python2.7/test/test_epoll
RUNNING /tmp/py271test/lib/python2.7/test/test_ftplib
OK
RUNNING /tmp/py271test/lib/python2.7/test/test_httplib
OK (skipped=1)
RUNNING /tmp/py271test/lib/python2.7/test/test_import
OK
RUNNING /tmp/py271test/lib/python2.7/test/test_kqueue
RUNNING /tmp/py271test/lib/python2.7/test/test_logging
OK
RUNNING /tmp/py271test/lib/python2.7/test/test_mailbox
OK
RUNNING /tmp/py271test/lib/python2.7/test/test_multiprocessing
...etc...

----------
nosy: +Jeff.Blaine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Mon Jul 18 02:57:06 2011
From: report at bugs.python.org (Jeff Blaine)
Date: Mon, 18 Jul 2011 00:57:06 +0000
Subject: [issue12013] file
	/usr/local/lib/python3.1/lib-dynload/_socket.so:	symbol
	inet_aton: referenced symbol not found
In-Reply-To: <1304644585.52.0.347221630935.issue12013@psf.upfronthosting.co.za>
Message-ID: <1310950626.45.0.213630971782.issue12013@psf.upfronthosting.co.za>


Changes by Jeff Blaine <cjblaine at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Mon Jul 18 02:59:56 2011
From: report at bugs.python.org (Julian)
Date: Mon, 18 Jul 2011 00:59:56 +0000
Subject: [issue12579] str.format_map raises a SystemError for format strings
	with positional arguments
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310950796.08.0.491446811397.issue12579@psf.upfronthosting.co.za>


Changes by Julian <Julian+Python.org at GrayVines.com>:


Removed file: http://bugs.python.org/file22682/format_map_err.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 03:00:44 2011
From: report at bugs.python.org (Julian)
Date: Mon, 18 Jul 2011 01:00:44 +0000
Subject: [issue12579] str.format_map raises a SystemError for format strings
	with positional arguments
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310950844.42.0.0608697858398.issue12579@psf.upfronthosting.co.za>


Julian <Julian+Python.org at GrayVines.com> added the comment:

Added, updated the patch :). Thank you!

----------
Added file: http://bugs.python.org/file22683/format_map_err.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 03:01:04 2011
From: report at bugs.python.org (Julian)
Date: Mon, 18 Jul 2011 01:01:04 +0000
Subject: [issue12579] str.format_map raises a SystemError for format strings
	with positional arguments
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <1310950864.86.0.374736875088.issue12579@psf.upfronthosting.co.za>


Changes by Julian <Julian+Python.org at GrayVines.com>:


Removed file: http://bugs.python.org/file22681/format_map_err.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 03:58:55 2011
From: report at bugs.python.org (Bharadwaj)
Date: Mon, 18 Jul 2011 01:58:55 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1310954335.51.0.293530696314.issue12524@psf.upfronthosting.co.za>


Bharadwaj <barbi.bruce at gmail.com> added the comment:

Newbie here. Please be patient.

When I tried using the POST form in this page, I ran into minor issues.
1. The form returns a 302 to the actual issue page. Some other example with 200 may be better.
2. The params are a little weird, with '@' in the names. Might be confusing for newbies.
3. Form action param is '#', which is not a great example.

Please suggest if I should continue with this example or find a better one.

Code:
import http.client, urllib.parse
params = urllib.parse.urlencode({'@number': 12524, '@type': 'issue', '@action': 'show'})
headers = {"Content-type": "application/x-www-form-urlencoded",
           "Accept": "text/plain"}
conn = http.client.HTTPConnection("bugs.python.org")
conn.request("POST", "#", params, headers)
response = conn.getresponse()
print(response.status, response.reason)
data = response.read()
conn.close()
data
b'Redirecting to <a href="http://bugs.python.org/issue12524">http://bugs.python.org/issue12524</a>'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Mon Jul 18 04:03:26 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 02:03:26 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1310954606.3.0.512495649417.issue12540@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This appears to be a Windows-only issue; I'm not able to readily reproduce it on either Linux or OS X.  Taking a quick look at diffs between 3.2 and 3.2.1, there aren't a lot of changes in IDLE (Lib/idlelib) and nothing obviously related.  There are a number of changes elsewhere in signal handling and process handling, though.  The restart_subprocess code is in Lib/idlelib/PyShell.py. If there isn't anything obvious elsewhere, perhaps someone can try to hg bisect it on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Mon Jul 18 04:18:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jul 2011 02:18:11 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <E1QidPI-0006s9-QM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aaced3dcb858 by Brett Cannon in branch 'default':
Make warnings accept a callable for showwarnings instead of
http://hg.python.org/cpython/rev/aaced3dcb858

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Mon Jul 18 04:19:13 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Jul 2011 02:19:13 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1310955553.73.0.764961830313.issue10271@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Committed in 3.3. This cannot be backported as it widens the API and those could lead to subtle incompatibilities.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Mon Jul 18 04:20:05 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 18 Jul 2011 02:20:05 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310955605.9.0.723979524199.issue12576@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Mon Jul 18 04:26:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jul 2011 02:26:00 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <E1QidWx-0007Om-GK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eaefb34fc3a1 by Brett Cannon in branch 'default':
Add Misc/NEWS entry and relevant doc change for issue 10271.
http://hg.python.org/cpython/rev/eaefb34fc3a1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Mon Jul 18 07:25:34 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 05:25:34 +0000
Subject: [issue11055] OS X IDLE 3.2 Save As menu accelerator opens two Save
	windows
In-Reply-To: <1296273818.82.0.517737090521.issue11055@psf.upfronthosting.co.za>
Message-ID: <1310966734.21.0.249780386022.issue11055@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

There is now a patch in the Tcl pipeline for this problem.  See:
http://permalink.gmane.org/gmane.comp.lang.tcl.mac/6965

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11055>
_______________________________________

From report at bugs.python.org  Mon Jul 18 07:46:29 2011
From: report at bugs.python.org (Petter Haggholm)
Date: Mon, 18 Jul 2011 05:46:29 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>


New submission from Petter Haggholm <petter at petterhaggholm.net>:

Some very trivial tests to increase the test coverage on test_urlparse a bit; also changed a single line to use an ABC instead of attempting to use len() to verify that an object is "sequence-like" (as the comment put it). Mostly I?m trying to get my feet wet in submitting a patch in the manner suggested by the guide.

(Curiously, the full test suite coverage report cites 99%, even though the path in question does run: coverage.py fails somehow to mark an else branch consisting of a lone continue statement.)

Looking at this, I have some questions, but figured I might as well ask them along with a patch: First, whether this is appropriate use of ABCs in the library; second, whether it?s appropriate to submit related stuff like modified tests and (lightly) modified code in one patch, or whether I should rather open two issues.

Third, and more generally, I?m wondering whether the tests are appropriate. These are trivial in scope and nature, but I would be interested to know for future reference (and perhaps it would be useful to mention in the docs?) what the policy is on this. Essentially, I encoded expectations of current behaviour as ?correct? and covered the 30-odd statements in urllib/parse.py that were not already covered by a full test run (explicit coverage by test_urlparse is still much lower!) on the assumption that, as the coverage guide suggests, more coverage is always better ? and even without domain expertise assurance that current behaviour is correct, it at least provides some assurance that changes in behaviour will be discovered. Still, it?s perhaps *too* easy to get hung up on those coverage percentages: Is it *always* better to cover more (keeping in mind the limitations of once-over coverage), or would contributors be better advised not to cover code unless they are very, very confident that current behaviour is correct?

----------
components: Tests
files: urlparsetest.patch
keywords: patch
messages: 140560
nosy: haggholm
priority: normal
severity: normal
status: open
title: Increased test coverage of test_urlparse
versions: Python 3.3
Added file: http://bugs.python.org/file22684/urlparsetest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Mon Jul 18 09:10:41 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 18 Jul 2011 07:10:41 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310973041.98.0.230056348653.issue5505@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Feel like a total noob: Where do I get the latest source? I can't find any pre-release tarballs for 3.3, and the suggested py3k checkout doesn't work: $ hg clone http://hg.python.org/cpython#py3k py3k
abort: unknown revision 'py3k'!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Mon Jul 18 09:14:16 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 07:14:16 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310973256.57.0.870879485731.issue5505@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

See the developer's guide: http://docs.python.org/devguide/setup.html#getting-the-source-code

   hg clone http://hg.python.org/cpython directory_name

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Mon Jul 18 09:17:54 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 18 Jul 2011 07:17:54 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310973474.51.0.411749003711.issue5505@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

This version is fixed for me:

$ ./python
Python 3.3.0a0 (default:7520f1bf0a81, Jul 18 2011, 17:12:12)
[GCC 4.1.2 20070115 (SUSE Linux)] on linux2

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Mon Jul 18 09:38:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jul 2011 07:38:47 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310974727.56.0.725209967005.issue5505@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@pitrou: Antoine, do you think that the following commit should be backported from 3.3 to 3.2?

New changeset 3c7792ec4547 by Victor Stinner in branch 'default':
Issue #12175: BufferedReader.read(-1) now calls raw.readall() if available.
http://hg.python.org/cpython/rev/3c7792ec4547

It changes BufferedReader.read() behaviour a *little* bit. Only a little because FileIO.read(-1) calls FileIO.readall() internally for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Mon Jul 18 09:40:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jul 2011 07:40:26 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1310974826.5.0.594487107621.issue12133@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I reopen the issue.

----------
resolution: fixed -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Mon Jul 18 09:41:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jul 2011 07:41:53 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1310974913.76.0.784873375167.issue12133@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(Oh, I missed Antoine's comment, yes, reopen a new issue)

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Mon Jul 18 10:27:11 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Mon, 18 Jul 2011 08:27:11 +0000
Subject: [issue12577] Misleading shutil.move docs regarding when os.rename is
	used
In-Reply-To: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>
Message-ID: <1310977631.79.0.214215494841.issue12577@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Senthil's proposal in msg140543 has +1 from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12577>
_______________________________________

From report at bugs.python.org  Mon Jul 18 10:31:54 2011
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Mon, 18 Jul 2011 08:31:54 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1310977914.64.0.318276764656.issue12133@psf.upfronthosting.co.za>


Ugra D?niel <daniel.ugra at gmail.com> added the comment:

Sorry, I've forgotten to post a reference to the new bug: #12576

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Mon Jul 18 11:00:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jul 2011 09:00:39 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310979639.88.0.917353203934.issue12576@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

h.close() (HTTPConnection.close) in the finally block of AbstractHTTPHandler.do_open() calls indirectly r.close() (HTTPResponse.close). The problem is that the content of the response cannot be read if its close() method was called.

The changelog of the fix (commit ad6bdfd7dd4b) is: "Issue #12133: AbstractHTTPHandler.do_open() of urllib.request closes the HTTP connection if its getresponse() method fails with a socket error. Patch written by Ezio Melotti."

The HTTP connection is not only closed in case of an error, but it is always closed.

It's a bug because we cannot read the content of www.imdb.com, whereas it works without the commit. Test script:
---------------
import urllib.request, gc

print("python.org")
with urllib.request.urlopen("http://www.python.org/") as page:
    content = page.read()
    print("content: %s..." % content[:40])
gc.collect()

print("imdb.com")
with urllib.request.urlopen("http://www.imdb.com/") as page:
    content = page.read()
    print("content: %s..." % content[:40])
gc.collect()

print("exit")
---------------

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Mon Jul 18 11:01:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jul 2011 09:01:51 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310979711.86.0.224840004979.issue12576@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ValueError('I/O operation on closed file') error comes from HTTPResponse.__enter__() which is implemented in IOBase:

    def __enter__(self):  # That's a forward reference
        self._checkClosed()
        return self

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Mon Jul 18 11:07:13 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Mon, 18 Jul 2011 09:07:13 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310980033.06.0.680435593841.issue12576@psf.upfronthosting.co.za>


Changes by Davide Rizzo <sorcio at gmail.com>:


----------
nosy: +davide.rizzo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Mon Jul 18 12:13:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jul 2011 10:13:39 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310984019.79.0.397977022522.issue12576@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

imdb.com and python.org use HTTP/1.1. imdb.com server sends a "Transfer-encoding: chunked" header whereas python.org doesn't. python.org has a "Connection: close" header, whereas imdb.com doesn't.

The more revelant difference for this issue is the "Connection: close" header: HTTPResponse.wil_close is True if "Connection: close" header is present (see _check_close() method), it returns False otherwise. HTTPConnection.getresponse() keeps a reference to the response if will_close is False, or calls its close() method otherwise.

The "Cneonction: close" header looks to be a quirk of Netscaler loadbalancers. It is sometimes "nnCoection" uses the same load balancer.

There are buggy web servers, Python should not raise a "I/O closed file" error on such server.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Mon Jul 18 13:32:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Jul 2011 11:32:43 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310988763.47.0.567441599222.issue5505@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, do you think that the following commit should be backported
> from 3.3 to 3.2?

No, I don't think so.

----------
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Mon Jul 18 14:17:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Jul 2011 12:17:49 +0000
Subject: [issue5505] sys.stdin.read() doesn't return after first EOF on Windows
In-Reply-To: <1237368034.29.0.0565107663013.issue5505@psf.upfronthosting.co.za>
Message-ID: <1310991469.97.0.59141362543.issue5505@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> No, I don't think so.

The issue is already fixed in 3.3, so you agree to not fix it in Python 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5505>
_______________________________________

From report at bugs.python.org  Mon Jul 18 15:22:08 2011
From: report at bugs.python.org (Steve Hill)
Date: Mon, 18 Jul 2011 13:22:08 +0000
Subject: [issue6476] MSVCRT's spawnve/spawnvpe are not thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <1310995328.83.0.996738547322.issue6476@psf.upfronthosting.co.za>


Steve Hill <python.20.hills at spamgourmet.com> added the comment:

Why has this bug been resolved as "won't fix"? It seems to me that this is a valid issue with something that has not been deprecated, yet it has been decided neither to fix it (despite there being an offer by the originator to submit a patch) nor even to document the deficiency.

We've been using SCons for the last 3-4 years, during which time we have been plagued by this issue - more so as multi-core machines have become more prevalent. There was a thread on the SCons Users mailing list in March '09, which stopped short of diagnosing the problem and we've lived with it ever since - putting it down to Python being "a bit flaky". I now discover that it is an issue that has been diagnosed two years ago and deliberately left in the implementation of the language. Simply saying "you should use subprocess" is not helpful; SCons at that time was supporting all Python versions back to 2.0 (possibly earlier) so couldn't rely on the subprocess module being present.

Ideally, it should be worked-around so that these functions can safely be used on all platforms without requiring mutual exclusion in the application. However, it seems to me that, at a bare minimum, it should be documented that these functions are not thread safe under Windows.

----------
nosy: +steve_hill

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6476>
_______________________________________

From report at bugs.python.org  Mon Jul 18 15:28:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jul 2011 13:28:40 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1310995720.44.0.443043388777.issue12581@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I haven't reviewed your tests, but a couple quick comments: we generally prefer duck typing to the use of isintance or ABCs, but sometimes the latter is better (it's a judgement call).  I haven't done a deep dive in the code you modified, but from the looks of the code quoted in your patch I'd say that doing 'iter(v)' inside the try/except would be the way to find out if one can loop over the object, which appears to be the only aspect of sequenceness the code cares about.

As for coverage, you are right that it is quite possible to get caught up in the statistics.  That said, if you *don't* have domain knowledge, giving us a set of tests to look at and evaluate is better than not having such a set of tests.  Pointing out any tests that you aren't sure about the validity of is helpful in any case.

The overall goal of the test suite is to test the *API* of the library functions.  This is so that alternate implementations can use it as a validation test suite  (Sometimes we have CPython specific tests, in which case we mark them as such).  So testing internal implementation details is not as helpful as testing behavior.  If you find you have to use a "white box" test (one that pokes at the internals as opposed to making an appropriate call to the API), then the code you can't otherwise test becomes suspect and an appropriate subject for another issue ("what is this code for?  I can't get it to trigger.")

Finally, your point about comprehensive tests at least showing up behavior changes is valid.  If you write tests that you aren't sure are "correct behavior", put in an XXX comment to that effect.  If you just have no idea, you can mark a whole block of tests as "this improves coverage, I have no idea if the behavior is valid or not", and we'll either sort it out when we review or commit the tests or just leave the comment in.

Thanks for working on this.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Mon Jul 18 15:28:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jul 2011 13:28:58 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1310995738.45.0.442916268907.issue12581@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Mon Jul 18 15:44:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 13:44:12 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1310996652.03.0.550857951556.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I would call .copy() on the original dicts rather than remembering an
> explicit empty dict.

I thought about that and decided to use an empty dict as a way to add a check that the caches should start empty.  Maybe it was misguided and I should instead add a unit test for that, or not bother altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Mon Jul 18 15:46:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 13:46:12 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1310996772.26.0.978920105037.issue1626300@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> On Windows, scripts run with whatever name -- no extension or other
> extensions.
Thanks, this means that the docs can continue to say just ?pysetup3?, without ?.py?.

(I wonder how Windows manages to run the script without file extension!)

> I have tested this from both IDLE and command line.
You can run command-line scripts from IDLE?

Can you also comment on my proposed note about adding Scripts to PATH?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Mon Jul 18 15:47:29 2011
From: report at bugs.python.org (Paul Weiss)
Date: Mon, 18 Jul 2011 13:47:29 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>


New submission from Paul Weiss <psw208 at gmail.com>:

I am trying to install python 2.7 on my Redhat machine. It installs most of the files, but it doesn't install the lib-dynload directory. I have set every path, done every install and clean I could think of but I can't get it to work. I have tried 2.7, 2.7.1 and 2.7.2 and none of them install. What could cause this?

----------
components: Build, Installation
messages: 140578
nosy: Paul.Weiss
priority: normal
severity: normal
status: open
title: lib-dynload missing in python install
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 15:57:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 13:57:22 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1310997442.87.0.656278555085.issue12582@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m assuming you?re installing a Python from python.org, not the one from Red Hat.  Can you give us the configure and make commands you ran?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:03:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:03:46 +0000
Subject: [issue12479] Add HTTPErrorProcessor class definition
In-Reply-To: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>
Message-ID: <1310997826.58.0.791442932058.issue12479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems to me that the doc after the patch is barely more helpful.  It does not explain when and how one would see or use the class, nor what it does.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12479>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:05:48 2011
From: report at bugs.python.org (Paul Weiss)
Date: Mon, 18 Jul 2011 14:05:48 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1310997948.4.0.647803293659.issue12582@psf.upfronthosting.co.za>


Paul Weiss <psw208 at gmail.com> added the comment:

Correct, I am using the source from 

http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tgz

make clean 
./configure --prefix=/opt/Python-2.7
make 
sudo make install 

I get this:

/usr/bin/install -c -m 644 ./LICENSE /opt/Python-2.7/lib/python2.7/LICENSE.txt
PYTHONPATH=/opt/Python-2.7/lib/python2.7   \
        ./python -Wi -tt /opt/Python-2.7/lib/python2.7/compileall.py \
        -d /opt/Python-2.7/lib/python2.7 -f \
        -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
        /opt/Python-2.7/lib/python2.7
Traceback (most recent call last):
  File "/opt/Python-2.7/lib/python2.7/compileall.py", line 17, in <module>
    import struct
  File "/opt/Python-2.7/lib/python2.7/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
make: *** [libinstall] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:07:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:07:42 +0000
Subject: [issue12479] Add HTTPErrorProcessor class definition
In-Reply-To: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>
Message-ID: <1310998062.17.0.320532219765.issue12479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, I see that the class is referenced earlier in the file, and that its methods come after.  I?d put the class definition just before the methods.  (I would even refactor the reST to use nested class/method combo, but that?s a minor markup cleanup, not a content improvement.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12479>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:08:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jul 2011 14:08:03 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1310998083.28.0.181861602657.issue12582@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Also, are you using a linux3 kernel?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:17:04 2011
From: report at bugs.python.org (Paul Weiss)
Date: Mon, 18 Jul 2011 14:17:04 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1310998624.55.0.78174766796.issue12582@psf.upfronthosting.co.za>


Paul Weiss <psw208 at gmail.com> added the comment:

No, Redhat's 2.6.9. Could that be the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:20:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:20:29 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1310998829.93.0.445122431684.issue12576@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/issue12576>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:21:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:21:32 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1310998892.87.0.336969112059.issue11468@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think there?s value in accepting the current patch as really basic example, and then see if the section about setting up and tearing down also has a very simple example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:25:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:25:43 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310999143.33.0.313204505034.issue1170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We all recognize that ASCII is very much limited and that the real way to work with strings is Unicode.  However, here our hands are tied by our development process: shlex in 2.x does not support Unicode, adding that support would be a new feature, and 2.7 is closed to new features.  If shlex was supposed to support Unicode, then this would be a bug that could be fixed in 2.7, but it?s not.  All we can do is improve the 2.7 doc to show how to work around that (splitting on bytes and then decoding each chunk, for example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:27:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:27:45 +0000
Subject: [issue12533] python-celementtree prevents me from running python
	develop.py to compile Imprudence Viewer
In-Reply-To: <1310394744.41.0.195161655519.issue12533@psf.upfronthosting.co.za>
Message-ID: <1310999265.0.0.541319688186.issue12533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  The Imprudence bug seems to confirm this is not a distutils bug.

----------
assignee:  -> eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12533>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:31:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:31:29 +0000
Subject: [issue12543] `issubclass(collections.deque,
	collections.Sequence) == False`
In-Reply-To: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>
Message-ID: <1310999489.45.0.582341527072.issue12543@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> They don't support slicing, certainly, but I can't tell from the
> collections ABC docs if Sequence is required to support slicing.

This looks like a 2.7 docs bug.  The table with ABCs mentions __*item__, but not __*slice__, probably because it was written with 3.x in mind (where slices are a type of __*item__).  Do you think we need to improve the documentation for slicing, in general and with regards to collections ABCs?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12543>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:36:08 2011
From: report at bugs.python.org (Jim Schneider)
Date: Mon, 18 Jul 2011 14:36:08 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1310999768.45.0.68988263947.issue12572@psf.upfronthosting.co.za>


Jim Schneider <jim.schneider at dataflux.com> added the comment:

Martin - I don't have time to manage your project's administrative requirements with respect to my fixes.  I'm providing them out of the hope they will be of use to others who need to build on HP/UX, but I don't really care if they make it into the main branch or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:36:33 2011
From: report at bugs.python.org (Doug Hellmann)
Date: Mon, 18 Jul 2011 14:36:33 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1310999793.41.0.927326823907.issue1170@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Is unicode supported by shlex in 3.x already? It's curious that unicode support is considered a new feature, rather than a bug. I understand wanting to allocate development resources carefully, though. If someone were to prepare a patch, would it even have a chance of being accepted in 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:43:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:43:38 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1311000218.9.0.464623290068.issue1170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See http://bugs.python.org/issue1170#msg106424 and following.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:51:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 14:51:59 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1311000719.69.0.670268137324.issue1170@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s not about allocating resources, it?s about following process.  The first part is that we don?t add new features to stable releases, the second item is that this is not considered a bug fix: The code pre-dates Unicode, was not updated to support it, and the docs say ?The shlex module currently does not support Unicode input?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Mon Jul 18 16:57:07 2011
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 18 Jul 2011 14:57:07 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311001027.24.0.499221834073.issue1626300@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I don't think that is the default state. You need to add .py to the PATHEXT environment variable:
http://effbot.org/pyfaq/how-do-i-make-python-scripts-executable.htm

Maybe Terry did this at some point? My windows box certainly does not have it and I have 2.6 and 2.7 installed. I don't have a 3.x install so I can't check if that is new in 3.

----------
nosy: +lambacck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Mon Jul 18 17:09:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jul 2011 15:09:37 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1311001777.02.0.143316987497.issue12582@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No.  We know we have some issues with platform stuff on linux3 kernels, though, which why I asked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 17:28:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jul 2011 15:28:18 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311002898.51.0.674525056512.issue1626300@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I perhaps misunderstood your question. I ran files from the command line as as 'python whatever', not 'whatever' so only python would care about an extension. I do not have a file association to 'run' a file, with or without .py. I presume IDLE does same when one RUNs a file, except with pythonw.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Mon Jul 18 17:39:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 15:39:22 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311003562.45.0.47024284938.issue1626300@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The original bug is that the distutils docs use commands like ?python setup.py spam? all over the place, and they don?t typically work
> because the python executable is not in the path in the default
> install.  'setup.py install' will work since .py files are associated
> with python.exe
(quoted from the first message).  I added a note to instruct Windows users to mentally replace those commands with ?setup.py spam?.

Now my concern is about packaging: In a typical Windows install, can people run ?pysetup3 spam??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Mon Jul 18 17:48:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 15:48:13 +0000
Subject: [issue12449] Add accelerator "F" to button "Finish" in all MSI
	installers made by bdist_msi
In-Reply-To: <1309419118.82.0.901696442421.issue12449@psf.upfronthosting.co.za>
Message-ID: <1311004093.48.0.488994777363.issue12449@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> My concern for MSI is that this issue is referencing a change to MSI
> generation. I never had any expectation for wininst to generate an MSI.
I?m sorry, it was me that first talked about wininst by mistake, the bug report always was about msi.

> If I remember correctly from trying the other day --formats=msi fails
> because bdist_msi is set as a valid format.
Also bdist_msi is only enabled on Windows.

> I have begun work on fixing these problems, as I've encountered them,
> and will be writing up issues for them soon.
Great!  Can you open bugs as soon as encountered?  Just say that you?re working on a patch to avoid work duplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12449>
_______________________________________

From report at bugs.python.org  Mon Jul 18 17:49:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 15:49:42 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311004182.29.0.682166492885.issue12531@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> [...] If the syntax *expression appears in the function call,
> expression must evaluate to a sequence.

An iterable :)

----------
nosy: +eric.araujo -ericsnow, terry.reedy
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Mon Jul 18 17:59:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 15:59:16 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311004756.04.0.878171460493.issue12531@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +ericsnow, terry.reedy
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Mon Jul 18 18:04:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 16:04:52 +0000
Subject: [issue12559] gzip.open() needs an optional encoding argument
In-Reply-To: <1310657482.81.0.606922001994.issue12559@psf.upfronthosting.co.za>
Message-ID: <1311005092.76.0.620258701795.issue12559@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/issue12559>
_______________________________________

From report at bugs.python.org  Mon Jul 18 18:07:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 16:07:27 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1311005247.52.0.180400602417.issue12560@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve looked at 3.x and think the patch would apply cleanly there too.

----------
nosy: +eric.araujo
stage:  -> commit review
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Mon Jul 18 18:18:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 16:18:46 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1311005926.87.0.271612716216.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Carl]
> there's an implicit assumption that a .pth file is the most likely
> strategy.
If you have other ideas, please share them.

[another message]
> I don't see why the installation-location-finding for develop should
> be any different than for a normal "pysetup install".
It?s only a technical limitation for now: the develop command is currently a standalone command, so it has to decide where to write stuff.  If it were an option to install_dist instead of a standalone command, then it would have paths processing already written.

Higery changed his code recently to get paths from the install_dist command instead of requiring site-packages.  (You can read the reviews, if you don?t mind style comments mixed with more important issues.)

> Does "pysetup install" install to global site-packages by default, or
> try to find somewhere it can install without additional privileges?
The install action can have a different behavior than the install_dist command.  develop is only a command now, and I agree it should behave like install_dist (which it now does).

> (though I don't really see the value in "arbitrary locations", since
> you then have to set up PYTHONPATH manually anyway).
We don?t know what people do, what with /opt installs and plugins and whatever, so there?s just no value in not allowing any path for install.

> Certainly "develop" should support PEP 370, ideally with the same
> command-line flag as a regular install.
Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Mon Jul 18 18:22:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 16:22:16 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1311006136.45.0.855762370974.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s the patch, please review.

----------
assignee:  -> eric.araujo
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22685/shlex.quote.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Mon Jul 18 18:23:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Jul 2011 16:23:56 +0000
Subject: [issue1284670] Allow to restrict ModuleFinder to get "direct"
	dependencies
Message-ID: <1311006236.74.0.72978414562.issue1284670@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I applied the patch, added a test and found a bug.  Here?s my progress so far; someone can start from it to write more tests and fix the code.

----------
nosy: +misc
Added file: http://bugs.python.org/file22686/modulefinder-no-recurse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284670>
_______________________________________

From report at bugs.python.org  Mon Jul 18 18:32:20 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 18 Jul 2011 16:32:20 +0000
Subject: [issue1284670] Allow to restrict ModuleFinder to get "direct"
	dependencies
Message-ID: <1311006740.35.0.402268280984.issue1284670@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284670>
_______________________________________

From report at bugs.python.org  Mon Jul 18 18:52:59 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 18 Jul 2011 16:52:59 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1310807043.84.0.00492707140306.issue12434@psf.upfronthosting.co.za>
Message-ID: <CAMMy=OsUjGbpnEh1=HygOQxkf24=Dtpuz0f7UZ7NksRft9A4_w@mail.gmail.com>


Daniel Stutzbach <stutzbach at google.com> added the comment:

On Sat, Jul 16, 2011 at 2:04 AM, Eli Bendersky <report at bugs.python.org>wrote:

> Therefore, I propose to change this error message to:
>  "unicode argument expected, got '%s'"
>  as Terry suggested.
>

Sounds good to me.

----------
Added file: http://bugs.python.org/file22687/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________
-------------- next part --------------
<div class="gmail_quote">On Sat, Jul 16, 2011 at 2:04 AM, Eli Bendersky <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;">
Therefore, I propose to change this error message to:<br>
??&quot;unicode argument expected, got &#39;%s&#39;&quot;<br>
??as Terry suggested.<br></blockquote><div><br></div><div>Sounds good to me.??</div></div><br>-- <br>Daniel Stutzbach<br>

From report at bugs.python.org  Mon Jul 18 19:08:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jul 2011 17:08:59 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311008939.38.0.150963176446.issue1626300@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I went back and reread from the beginning, instead of merely answering the question you asked when adding me as nosy. More comments:

Windows file associations are so disfunctional that you should not depend on them being anything in particular. I nearly always open files from within applications (IDLE for python files) or with RightClick context menu when an entry specifies the app that will be used (as with 'Edit with Notepad++' (getting Python make such is another issue). The only way I can run from Command Prompt is to cd to the appropriate pythonxy directory and enter 'python full\path\to\file' (with stupid backslashes or 'python -m module' (which looks for module under /Lib). 

In XP, and I presume later, the term 'DOS box' is obsolete and I would delete it. The 'Command Prompt' app (with caps) is found in the Start/Accessories directory. So I would say "open a Command Prompt window (in Start/Accessories)"

Back to your message where you added me. I am not sure of the difference between 'local script' and 'global command'. I do not understand your proposed note, especially "*include link to relevant section of docs.python.org/using*.".

Script run without extensions when run with an explicit python command.
I was primed to answer this because someone recently, on the tracker or python-list, proposed to 'fix' a problem (wrongly) by adding a .py(o/w) extension check to determine if a file is Python code before running it.

I am not sure what 'or does the installer add .py?' could mean. The Windows installer? 'Add' to what? 

I realize that my answers may appear naive. I hope usefully so. I have used Windows since Win95 and have learned to focus, as described above, on what dependably works with minimal surprise. The extremely few 3rd party Python-based stuff I have installed has either come as a zipped library I could extract into site-packeges or as an independent app to be unzipped elsewhere or installed with a Windows-style installer. I have never used setup.py so no expert advice on its successor from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Mon Jul 18 19:15:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 18 Jul 2011 17:15:51 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <CAK=_o0htMjFjEr1MMfR7NzFEMvDW-smGF_steVLbTJn9n_8r1A@mail.gmail.com>
Message-ID: <CAH_1eM2vcZCg6uzvjZ3BFHOdL6naSLCRDDu4y16+cLASbv-iKA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So even on solaris the behavior seems to be filesystem dependent.
>

So  I'd suggest forgetting about this part.
Would you like to write a patch for the first point?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Mon Jul 18 19:20:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 18 Jul 2011 17:20:24 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <1311009624.07.0.911014830555.issue12372@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

So, what do we do now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Mon Jul 18 19:21:06 2011
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 18 Jul 2011 17:21:06 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311009666.5.0.152188388389.issue1626300@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

> Now my concern is about packaging: In a typical Windows install, can people run ?pysetup3 spam??

The windows installer does not make any additions to the path so it is unlikely that "pysetup3 spam" will work.

There is http://www.python.org/dev/peps/pep-0397/ which addresses running scripts in a multi-version windows environment but I don't think that will help in this case. 

If you are running more than 1 version of windows there is simple statement that tells you how to install and have the install go to the right interpreter. You are almost best to have a shortcut that gives you a command prompt with the PATH variable correctly set to the desired python instance. That does not help the 2.x crowd or anyone before 3.3 :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Mon Jul 18 19:26:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 18 Jul 2011 17:26:30 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za>
Message-ID: <1311009990.93.0.133179836732.issue11877@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Trying to revive this issue, here's a comment I left on Rietveld:

"""
> I don't agree, the documentation states that full_sync will cause a flush to
> stable storage where supported and a plain fsync where it isn't. This code
does
> just that.
>

I think I wasn't clear enough, so let me rephrase: the call to fcntl is guarded
by #ifdef, so it is only called on platforms where it is supported, otherwise
fsync() is called. What I was referring to is the fact that an fsync is tried if
the call to fcntl fails with ENOTTY: if I ask my operating system to flush disk
buffers and it can't, then I'd rather have an error returned, so that I can take
the right decision (abort, roll-back, try a classical fsync). IMHO, silently
masking an error by falling back to another syscall is wrong.
"""

Anyway, I think this patch can be useful (see for example issue #8604 as a typical use case). I personally don't care since I use Linux, but OS-X and *BSD folks might find some interest in this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Mon Jul 18 19:39:34 2011
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 18 Jul 2011 17:39:34 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311010774.87.0.584674474896.issue1626300@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

> I am not sure of the difference between 'local script' and 'global command'

local script is the setup.py (or for that matter any other script in an arbitrary place in the filesystem. Global command is referring to something installed in %PYTHONINSTALLDIR%\scripts i.e. it is an installed command. This one operates on a specific version instance of python. I for instance have c:\python26\scripts\easy_install.exe and c:\python27\script\easy_install.exe and each of those operates on their own particular version. Neither are in my path. The current state is that I have to either put one of the scripts directories in my path or run easy_install with the full path. My understanding is that pysetup is a replacement for easy_install that will come with 3.3.

> I am not sure what 'or does the installer add .py?' could mean. The Windows installer? 'Add' to what? 

I was referring .py being added to the PATHEXT evironment variable. I think it is safe to say that has not happened and is likely a bad idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Mon Jul 18 20:03:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jul 2011 18:03:53 +0000
Subject: [issue12579] str.format_map raises a SystemError for format strings
	with positional arguments
In-Reply-To: <1310913822.76.0.585550684788.issue12579@psf.upfronthosting.co.za>
Message-ID: <E1QisAZ-0008I8-SS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f6d074a7bbd4 by Eric V. Smith in branch '3.2':
Closes #12579. Positional fields with str.format_map() now raise a ValueError instead of SystemError.
http://hg.python.org/cpython/rev/f6d074a7bbd4

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12579>
_______________________________________

From report at bugs.python.org  Mon Jul 18 21:14:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jul 2011 19:14:08 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311016448.14.0.493114570589.issue12531@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would not propose to do everything in one grand patch as it would be way too much to review all at once. A somewhat separate subissue is whether there should be however many separate issues over the next however many years or one master issue with multiple patches.

The existing patch is enough to review for now. It needs changes and should add everything needed just for * and **. And there may be some unwritten policy issues.

I agree that the directive for * should be moved as Eli says.
I think 'statement' should be changed to 'function calls', or maybe 'in function calls' or 'function call operator' for both * and **.
The same directives should be added to the tutorial at the top and middle of Tutorial 4.7.4 Unpacking Argument Lists.
The existing * and ** 'statement' directives for defs in both tutorial and reference should become 'function defs' (or 'definitions') or 'in def statement'.
The existing * 'operator' directive should be 'number multiplication' or 'number multiplication operator' or at least 'number operator'.
Perhaps it (and the following) should be duplicated in the tutorial.
A new * 'sequence repetition* directive should be added.
The existing ** 'operator' directive should be 'number exponentiation'.
New 'assigment' and 'import' directives are needed.

I think *all* the entries for a given symbol should be considered together so that they can be properly differentiated. We should minimize duplicates that appear like this -- 'statement, [1]' -- and such duplicates should refer to the *same* usage. 

Policy issues:

I think 'statement' should be reserved for statement keywords like def, class, etc. Things in statements should be at least qualified as 'in <specific> statement.

I see that plain 'operator' is currently used for most or all operators. I think they should at least be qualified as to category -- number operator, seqeunce operator, comparision operator, logic operator, etc. This might tell users all they need to know and would separate overloaded operators like '*'.

Both general suggestions follow other usages. Classes are specified as 'class in <modname>', not just 'class'. Functions are specified not just with '()' but also 'in <modname>' Expanding 'statement' to 'in <keyword> statement' or something would be in the same spirit. Methods are specified as '<class> method', not just 'method'. Operators should get the same differentiation with at least '<optype> operator' if not more detail.

[separate issue note: 'as' seems not to be indexed.]

Adding Georg as I am suggesting a deviation from certain precedents (and conformance to others).

----------
nosy: +georg.brandl
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Mon Jul 18 21:21:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Jul 2011 19:21:27 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311016887.57.0.681949350312.issue12531@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> expression must evaluate to a sequence.

To be clear, Eli quoted the doc correctly and Eric correctly suggested that 'sequence' needs to be updated to 'iterable' (in at least two places). Since the patch for this issue will be adding something just above, it could just as well make this change also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Mon Jul 18 22:45:28 2011
From: report at bugs.python.org (Paul Weiss)
Date: Mon, 18 Jul 2011 20:45:28 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1311021928.28.0.167668359205.issue12582@psf.upfronthosting.co.za>


Paul Weiss <psw208 at gmail.com> added the comment:

So I have solved my own issue, but the solution raises another question. Let me explain...

On a whim I copied the build/lib.linux-i686-2.7 directory into the /opt/Python-2.7/lib/python2.7 directory as lib-dynload. This worked and python installed correctly. In a quick test it looks like everything is fine. 

But now my question is, why didn't that directory get copied during the build?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 22:45:33 2011
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 18 Jul 2011 20:45:33 +0000
Subject: [issue12583] More detailed `ImportError` messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

I've been frustrated so many times by `ImportError: cannot import name foo`. Right now I'm debugging some problem on a PAAS server (with no SSH access), and the server returns a traceback of `cannot import name foo`, and I don't have any idea what it means. It could mean that the file isn't there. It could mean that there's a circular import problem. Sometimes it happens when you go over Windows XP's path length limit!

Please provide a useful explanation, like this:

    ImportError: Cannot import `foo` because no file foo.py* or folder foo exists.
    ImportError: Cannot import foo module because no __init__.py* file exists in the foo folder.
    ImportError: Cannot import foo because of a circular import problem with bar.
    ImportError: Cannot import foo because the foo module file's path is bigger than Windows XP's path length limit.

Etcetera for any other reason that might cause an `ImportError`.

----------
components: Interpreter Core
messages: 140614
nosy: cool-RR
priority: normal
severity: normal
status: open
title: More detailed `ImportError` messages
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Mon Jul 18 22:49:33 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Jul 2011 20:49:33 +0000
Subject: [issue12583] More detailed `ImportError` messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311022173.02.0.839493630719.issue12583@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Rather than mucking with the string, we should probably set some of these details as attributes on ImportError. #10854 wanted something similar - details on the pyd file that failed if you get an ImportError on an extension module on Windows.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Mon Jul 18 22:52:17 2011
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 18 Jul 2011 20:52:17 +0000
Subject: [issue12583] More detailed `ImportError` messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311022337.02.0.689371588026.issue12583@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

As long as those attributes are reflected in the string in human language, why not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:04:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Jul 2011 21:04:51 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1311023091.1.0.0895698192495.issue12582@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, at this point we have no idea.  It works fine for us.  This part is all controlled by the Makefile, maybe you can do some debugging on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:05:47 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 18 Jul 2011 21:05:47 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1311023147.79.0.947868952134.issue2259@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

Adding a test that opens the 24b48k.aif file, gets some information and does navigation on it. I'm aware that it doesn't triggers any extra failure against the actual tip (5a1bb8d4afd7) but it does if r72100 is undone (with some small rework :)). I'm not sure if that is the kind of test needed (if not just ignore it).

----------
nosy: +francismb
Added file: http://bugs.python.org/file22688/test_issue2259.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:19:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 21:19:21 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1311023961.04.0.204009712068.issue12582@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Works for me on another unix-y system.  I don't see any reason in configure.in or Makefile.pre.in why this shouldn't work assuming "make" is working as expected.  What version of "make" are you using?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:23:01 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 21:23:01 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1311024181.69.0.691933094708.issue12582@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Or possibly "install".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:32:05 2011
From: report at bugs.python.org (Paul Weiss)
Date: Mon, 18 Jul 2011 21:32:05 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1311024725.69.0.880141417534.issue12582@psf.upfronthosting.co.za>


Paul Weiss <psw208 at gmail.com> added the comment:

As it turns out I am using an older version of make on the machine that I was having trouble with. It seems we have made some bad assumptions about the configuration of our machines. It makes sense with other problems we have had on the other machines too. I am going to declare that the root cause of the issues. Thank you all for your help! Good call Ned, I am slightly embarrassed that I didn't think of that earlier.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:38:04 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 21:38:04 +0000
Subject: [issue12582] lib-dynload missing in python install
In-Reply-To: <1310996849.21.0.605822400677.issue12582@psf.upfronthosting.co.za>
Message-ID: <1311025084.0.0.0283552145778.issue12582@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution: fixed -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12582>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:41:03 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Jul 2011 21:41:03 +0000
Subject: [issue12583] More detailed `ImportError` messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311025263.41.0.308108634543.issue12583@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The problem with this request is it is practically unworkable. For instance, the missing __init__.py already exists as an ImportWarning. The circular import is a problem as Python would have to detect circular imports which is hard, else we would have a circular import solution. =)

We could fix the ImportError when running into stupid XP issues, but that requires someone to submit a patch enough to care to fix it. =)

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:48:36 2011
From: report at bugs.python.org (Andy Wildenberg)
Date: Mon, 18 Jul 2011 21:48:36 +0000
Subject: [issue12584] win.protocol('WM_DELETE_WINDOW'...) still deletes window
	on OSX
In-Reply-To: <1311025716.17.0.268047482862.issue12584@psf.upfronthosting.co.za>
Message-ID: <1311025716.17.0.268047482862.issue12584@psf.upfronthosting.co.za>


New submission from Andy Wildenberg <andy.wildenberg at gmail.com>:

This was originally posted on http://stackoverflow.com/questions/1800452/how-to-intercept-wm-delete-window-on-osx-using-tkinter but seems not to have been reported as a bug.

On OS X (10.6.8, python 2.6.1) register a protocol on 'WM_DELETE_WINDOW'.  Your callback will get called when the user clicks on the red "kill" icon in the top-left of the window, but the window will still be destroyed.  The same file on Python 2.6.5 Linux behaves as it should, i.e. the "kill" icon is effectively disabled on the "win" window.

----------
assignee: ronaldoussoren
components: Macintosh, Tkinter
files: bug.py
messages: 140624
nosy: Andy.Wildenberg, ronaldoussoren
priority: normal
severity: normal
status: open
title: win.protocol('WM_DELETE_WINDOW'...) still deletes window on OSX
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file22689/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12584>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:52:20 2011
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 18 Jul 2011 21:52:20 +0000
Subject: [issue12583] More detailed `ImportError` messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311025940.53.0.521407582517.issue12583@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

What's the problem with detecting circular imports? Mind you that we only need a post-mortem analysis to check why the import failed; so after the import failed, we could check whether our import stack has a loop in it.

I'm not familiar with the ImportWarning regarding `__init__.py`. Is this written about anywhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Mon Jul 18 23:54:00 2011
From: report at bugs.python.org (Philip Horger)
Date: Mon, 18 Jul 2011 21:54:00 +0000
Subject: [issue12570] BaseHTTPServer.shutdown() locks if the last request 404'd
In-Reply-To: <1310756079.18.0.187636465721.issue12570@psf.upfronthosting.co.za>
Message-ID: <CAHAkNZ06Qe5Y+mWFn1yXzgTpy_03T1N08M__g-fWpyLM-UHmTA@mail.gmail.com>


Philip Horger <campadrenalin at gmail.com> added the comment:

I'm having trouble replicating the issue in simpler code snippets than the
project code the issue first popped up in, which means the problem is
probably my own code. For now, it looks like this was a false alarm, and I'm
sorry for wasting anyone's time. I normally do more research on my own
before submitting bugs, but at the time I hit the submit button I literally
had 10 seconds of internet left, so I was a bit crunched for time.

On Fri, Jul 15, 2011 at 11:54 AM, Petri Lehtinen <report at bugs.python.org>wrote:

>
> Changes by Petri Lehtinen <petri at digip.org>:
>
>
> ----------
> nosy: +petri.lehtinen
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12570>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22690/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12570>
_______________________________________
-------------- next part --------------
I&#39;m having trouble replicating the issue in simpler code snippets than the project code the issue first popped up in, which means the problem is probably my own code. For now, it looks like this was a false alarm, and I&#39;m sorry for wasting anyone&#39;s time. I normally do more research on my own before submitting bugs, but at the time I hit the submit button I literally had 10 seconds of internet left, so I was a bit crunched for time.<br>
<br><div class="gmail_quote">On Fri, Jul 15, 2011 at 11:54 AM, Petri Lehtinen <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>
Changes by Petri Lehtinen &lt;<a href="mailto:petri at digip.org">petri at digip.org</a>&gt;:<br>
<br>
<br>
----------<br>
nosy: +petri.lehtinen<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/issue12570" target="_blank">http://bugs.python.org/issue12570</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Jul 18 23:58:24 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 21:58:24 +0000
Subject: [issue12521] IDLE 3.2 crashes on Mac OS 10.6 with ActiveState Tcl/Tk
	8.5
In-Reply-To: <1310177037.34.0.820762578532.issue12521@psf.upfronthosting.co.za>
Message-ID: <1311026304.84.0.03057013933.issue12521@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Since there has been no response, I am closing this.  Please re-open if you can still reproduce the crash and, if so, supply the requested information so we can investigate further.

----------
resolution:  -> works for me
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12521>
_______________________________________

From report at bugs.python.org  Tue Jul 19 00:12:21 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Jul 2011 22:12:21 +0000
Subject: [issue12584] win.protocol('WM_DELETE_WINDOW'...) still deletes window
	on OSX
In-Reply-To: <1311025716.17.0.268047482862.issue12584@psf.upfronthosting.co.za>
Message-ID: <1311027141.45.0.774220850293.issue12584@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Works for me using the Pythons installed from the python.org 2.6.6 or 2.7.2 installer and with the current ActiveState Tcl/Tk 8.4 (for 2.6.6) and 8.5 (for 2.7.2) releases installed.  Chances are this was a bug in the Apple-supplied Cocoa Tcl/Tk 8.5 released with OS X 10.6 and used by the Apple-supplied Pythons in 10.6.  There are many known problems with the Apple-supplied version of Tcl/Tk 8.5.  We strongly recommend that you not attempt to use it.  See: http://www.python.org/download/mac/tcltk/

----------
assignee: ronaldoussoren -> ned.deily
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/issue12584>
_______________________________________

From report at bugs.python.org  Tue Jul 19 00:23:53 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jul 2011 22:23:53 +0000
Subject: [issue12570] BaseHTTPServer.shutdown() locks if the last request 404'd
In-Reply-To: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>
Message-ID: <1311027833.51.0.470919101147.issue12570@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Not a problem. I am closing this, but if you find enough evidence that something is a bug, feel free to reopen this or another report.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12570>
_______________________________________

From report at bugs.python.org  Tue Jul 19 00:23:59 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jul 2011 22:23:59 +0000
Subject: [issue12570] BaseHTTPServer.shutdown() locks if the last request 404'd
In-Reply-To: <1310687345.57.0.299486964146.issue12570@psf.upfronthosting.co.za>
Message-ID: <1311027839.25.0.734359569765.issue12570@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


Removed file: http://bugs.python.org/file22690/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12570>
_______________________________________

From report at bugs.python.org  Tue Jul 19 00:27:05 2011
From: report at bugs.python.org (Philip Horger)
Date: Mon, 18 Jul 2011 22:27:05 +0000
Subject: [issue12570] BaseHTTPServer.shutdown() locks if the last request 404'd
In-Reply-To: <1311027839.28.0.440875643031.issue12570@psf.upfronthosting.co.za>
Message-ID: <CAHAkNZ3wzL6SVHNoRGXo-VBPPfsg6UKJx0q79ax9FhrWn6c2jQ@mail.gmail.com>


Philip Horger <campadrenalin at gmail.com> added the comment:

Thanks, sounds good to me too. I'll probably work on it a bit later, see if
I can find the bug in my own code at least.

On Mon, Jul 18, 2011 at 3:23 PM, Senthil Kumaran <report at bugs.python.org>wrote:

>
> Changes by Senthil Kumaran <senthil at uthcode.com>:
>
>
> Removed file: http://bugs.python.org/file22690/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12570>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22691/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12570>
_______________________________________
-------------- next part --------------
Thanks, sounds good to me too. I&#39;ll probably work on it a bit later, see if I can find the bug in my own code at least.<br><br><div class="gmail_quote">On Mon, Jul 18, 2011 at 3:23 PM, Senthil Kumaran <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>
Changes by Senthil Kumaran &lt;<a href="mailto:senthil at uthcode.com">senthil at uthcode.com</a>&gt;:<br>
<br>
<br>
Removed file: <a href="http://bugs.python.org/file22690/unnamed" target="_blank">http://bugs.python.org/file22690/unnamed</a><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/issue12570" target="_blank">http://bugs.python.org/issue12570</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From senthil at uthcode.com  Tue Jul 19 01:27:54 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 19 Jul 2011 07:27:54 +0800
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <1310884344.88.0.202316551835.issue11343@psf.upfronthosting.co.za>
References: <1298759991.59.0.16834388397.issue11343@psf.upfronthosting.co.za>
	<1310884344.88.0.202316551835.issue11343@psf.upfronthosting.co.za>
Message-ID: <20110718232754.GA2599@mathmagic>

Oh, I thought we never rely on exception "message" for anything
important. However this seems to be an exception for that exception.
:-)


From report at bugs.python.org  Tue Jul 19 01:28:02 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jul 2011 23:28:02 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <1310884344.88.0.202316551835.issue11343@psf.upfronthosting.co.za>
Message-ID: <20110718232754.GA2599@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Oh, I thought we never rely on exception "message" for anything
important. However this seems to be an exception for that exception.
:-)

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Tue Jul 19 01:30:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Jul 2011 23:30:36 +0000
Subject: [issue6476] MSVCRT's spawnve/spawnvpe are not thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <E1QixGl-0002ip-6u@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3fa7581f6d46 by Antoine Pitrou in branch '2.7':
Issue #6476: Document that os.spawnle and os.spawnve are not thread-safe under Windows.
http://hg.python.org/cpython/rev/3fa7581f6d46

New changeset a01ba3c32a4b by Antoine Pitrou in branch '3.2':
Issue #6476: Document that os.spawnle and os.spawnve are not thread-safe under Windows.
http://hg.python.org/cpython/rev/a01ba3c32a4b

New changeset aee7c27ea7df by Antoine Pitrou in branch 'default':
Issue #6476: Document that os.spawnle and os.spawnve are not thread-safe under Windows.
http://hg.python.org/cpython/rev/aee7c27ea7df

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6476>
_______________________________________

From senthil at uthcode.com  Tue Jul 19 01:31:04 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 19 Jul 2011 07:31:04 +0800
Subject: [issue12479] Add HTTPErrorProcessor class definition
In-Reply-To: <1310998062.17.0.320532219765.issue12479@psf.upfronthosting.co.za>
References: <1309697619.94.0.838258559522.issue12479@psf.upfronthosting.co.za>
	<1310998062.17.0.320532219765.issue12479@psf.upfronthosting.co.za>
Message-ID: <20110718233104.GB2599@mathmagic>

On Mon, Jul 18, 2011 at 02:07:42PM +0000, ?ric Araujo wrote:
> I?d put the class definition just before the methods.  (I would even
> refactor the reST to use nested class/method combo...

This is a good suggestion. It would good to do some point in time soon.
Thanks!

From report at bugs.python.org  Tue Jul 19 01:31:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Jul 2011 23:31:12 +0000
Subject: [issue12479] Add HTTPErrorProcessor class definition
In-Reply-To: <1310998062.17.0.320532219765.issue12479@psf.upfronthosting.co.za>
Message-ID: <20110718233104.GB2599@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Mon, Jul 18, 2011 at 02:07:42PM +0000, ?ric Araujo wrote:
> I?d put the class definition just before the methods.  (I would even
> refactor the reST to use nested class/method combo...

This is a good suggestion. It would good to do some point in time soon.
Thanks!

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12479>
_______________________________________

From report at bugs.python.org  Tue Jul 19 01:31:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Jul 2011 23:31:31 +0000
Subject: [issue6476] MSVCRT's spawnve/spawnvpe are not thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <1311031891.14.0.671513807006.issue6476@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've made the necessary doc changes. I leave it open because I'm not sure what to do with the bugfix request (I agree with the general suggestion to use subprocess instead, though).

----------
nosy: +pitrou
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6476>
_______________________________________

From report at bugs.python.org  Tue Jul 19 01:34:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Jul 2011 23:34:38 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <20110718232754.GA2599@mathmagic>
Message-ID: <1311032004.3620.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Oh, I thought we never rely on exception "message" for anything
> important. However this seems to be an exception for that exception.
> :-)

I think you're missing the point. People usually don't catch SyntaxError
and run fallback code in this case. And even if they do, they are
unlikely to care about whether the ErreurDeSyntaxe is due to a genuinely
faulty piece of code, or a parser limitation ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Tue Jul 19 02:06:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jul 2011 00:06:05 +0000
Subject: [issue12577] Misleading shutil.move docs regarding when os.rename is
	used
In-Reply-To: <1310893161.81.0.334547060207.issue12577@psf.upfronthosting.co.za>
Message-ID: <E1Qixp6-00057L-Aa@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 62048a6eb43c by Senthil Kumaran in branch '3.2':
Fix closes issue12577 - clarify shutil.move documentation. Patch suggestion by Catalin Iacob
http://hg.python.org/cpython/rev/62048a6eb43c

New changeset 912b97ee40a7 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes issue12577 - clarify shutil.move documentation. Patch suggestion by Catalin Iacob
http://hg.python.org/cpython/rev/912b97ee40a7

New changeset 33f09733612e by Senthil Kumaran in branch '2.7':
merge from 3.2 - Fix closes issue12577 - clarify shutil.move documentation. Patch suggestion by Catalin Iacob
http://hg.python.org/cpython/rev/33f09733612e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12577>
_______________________________________

From report at bugs.python.org  Tue Jul 19 02:19:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jul 2011 00:19:52 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1311034792.46.0.229441503017.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch the _curses module to improve Unicode support:

 - add an encoding attribute to a window (only visible in C): read the locale encoding
 - encode a character and a character string to the window encoding if the ncursesw library is NOT used
 - addch(), addstr(), addnstr(), insstr() and insnstr() use the wide character functions if the ncursesw library is used
 - PyCurses_ConvertToChtype() checks for integer overflow and rejects values outside [0; 255]

The check on the ncursesw library availability is done in setup.py because the library linked to _curses depends on the readline library (see issues #7384 and #9408).

I don't know if wide character functions can be available in curses or ncurses library.

Details:

 - locale encoding: use GetConsoleOutputCP() on Windows, nl_langinfo(CODESET) if available, or "utf-8"
 - don't encode a character to the window encoding if its code is in [0; 127] (use the Unicode point code): all encoding are compatible with ASCII... except some encodings like JIS X 0201. In JIS, 0x5C is decoded to the yen sign (U+00A5) instead of a backslash (U+005C).
 - if an encoded character is longer than 1 byte, raise a OverflowError. For example, U+00E9 (?) encoded to UTF-8 gives b'\xC3\xA9' (two bytes).
 - copy the encoding when creating a subwindow.
 - use a global variable, screen_encoding, in PyCurses_UnCtrl() and PyCurses_UngetCh()

It's not possible to specify an encoding.

GetConsoleOutputCP() is maybe not the right code on Windows if a text application doesn't run in a Windows console (e.g. if it uses its own terminal emulator). GetOEMCP() is maybe a better choice, or a function should be added to specify the encoding used by the _curses module (override the "locale encoding").

If a function is added to specify the encoding, I think that it is better to add a global function instead of adding an argument to functions creating a new window object (initscr(), getwin(), subwin(), derwin(), newpad()).

----------
Added file: http://bugs.python.org/file22692/curses_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Tue Jul 19 02:26:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jul 2011 00:26:29 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1311035189.33.0.022651333168.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using curses_unicode.patch:

 - without ncursesw: addch('?') raises an OverflowError because '?'.encode('UTF-8') is 2 bytes and not 1 byte
 - with ncursesw: the charset is displayable character depends on the locale encoding (e.g. ? cannot be printed with ISO-8859-1 locale encoding)
 - with ncursesw: any character can be printed with a UTF-8 locale encoding (including non-BMP characters: U-10000..U+10FFFF)

It would be possible to support multibyte encoded character (like ? in UTF-8) for addch() by calling addch() multiple times, one per byte, but I would prefer to keep _curses simple and not workaround libncurses limitations (bugs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Tue Jul 19 02:28:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jul 2011 00:28:16 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1311035296.81.0.911200436004.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #6755 (curses.get_wch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Tue Jul 19 02:30:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jul 2011 00:30:11 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1311035411.48.0.754244643605.issue6755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> implicit declaration of function ?wget_wch?

curses_unicode.patch of issue #12567 adds a HAVE_NCURSESW define to only use wide character functions if _curses is linked to libncursesw.

This define can be used to fix this bug (use wget_ch whereas it is not available).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Tue Jul 19 02:54:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 00:54:09 +0000
Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b")
In-Reply-To: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za>
Message-ID: <1311036849.95.0.180851241273.issue1221@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg59741

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1221>
_______________________________________

From report at bugs.python.org  Tue Jul 19 02:56:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 00:56:40 +0000
Subject: [issue1221] email.Utils.parseaddr("a(WRONG)@b")
In-Reply-To: <1191155944.58.0.169174625904.issue1221@psf.upfronthosting.co.za>
Message-ID: <1311037000.76.0.3288727818.issue1221@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Woops, hit a button wrong and managed to delete a message.  It just said:

See Issue1025395

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1221>
_______________________________________

From report at bugs.python.org  Tue Jul 19 03:30:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Jul 2011 01:30:38 +0000
Subject: [issue12543] `issubclass(collections.deque,
	collections.Sequence) == False`
In-Reply-To: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>
Message-ID: <1311039038.87.0.640915837744.issue12543@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

?ric, this is not a doc bug.  The sequence ABCs do not require slicing support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12543>
_______________________________________

From report at bugs.python.org  Tue Jul 19 03:43:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jul 2011 01:43:51 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <E1QizLh-00038o-VR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c4d884d5d86c by R David Murray in branch '2.7':
#7484: no more <> around addresses in VRFY or EXPN
http://hg.python.org/cpython/rev/c4d884d5d86c

New changeset f8c4ac9aa9e2 by R David Murray in branch '3.2':
#7484: no more <> around addresses in VRFY or EXPN
http://hg.python.org/cpython/rev/f8c4ac9aa9e2

New changeset 0d9216de8f05 by R David Murray in branch 'default':
Merge #7484: no more <> around addresses in VRFY or EXPN
http://hg.python.org/cpython/rev/0d9216de8f05

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Tue Jul 19 04:00:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jul 2011 02:00:10 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <E1QizbV-0004MY-JI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 50b6c3053c30 by R David Murray in branch 'default':
#7484: simplify quoteaddr: if parseaddr throws an error it is a bug.
http://hg.python.org/cpython/rev/50b6c3053c30

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Tue Jul 19 04:09:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 02:09:55 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1311041395.51.0.38301259116.issue7484@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thank you both for your work on this.  The patch I committed is a combination of my _addr_only, Filipe's tests, and Catalin's modifications to those tests.  quoteaddr, although in the __all__, is not documented and is really an implementation detail, as is the new _addr_only.  So I am only testing them indirectly through the documented parts of the API (I added a test for <> address, and one for an IDNA encoded address).

Catalin, I think you are correct about the try/except/None stuff.  As far as I can tell it is left over from the old days before the email package and its philosophy of never throwing parsing errors.  Nowadays if parseaddr throws an error, it is a bug.  That's a refactoring not a bug fix, though, so I didn't backport it.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Tue Jul 19 04:11:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Jul 2011 02:11:21 +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: <1311041481.71.0.997060343487.issue11343@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, at the level of *code* the origin doesn't really matter, so re-using the exception type is actually OK. However, for *people* seeing the stack trace, it may be useful to know what's genuinely illegal syntax and what's a limitation of the current implementation. The exception message is a good place for that additional detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Tue Jul 19 04:17:10 2011
From: report at bugs.python.org (Felipe Cruz)
Date: Tue, 19 Jul 2011 02:17:10 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1311041395.51.0.38301259116.issue7484@psf.upfronthosting.co.za>
Message-ID: <CAEynwxsg=joBy4hrW3CY+APONROh=fnELSR9Oon=9Vrq7yO=8w@mail.gmail.com>


Felipe Cruz <felipecruz at loogica.net> added the comment:

You're very kind David.

Hope I can contribute with something more relevant next time :)

best regards,
Felipe

2011/7/18 R. David Murray <report at bugs.python.org>

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Thank you both for your work on this.  The patch I committed is a
> combination of my _addr_only, Filipe's tests, and Catalin's modifications to
> those tests.  quoteaddr, although in the __all__, is not documented and is
> really an implementation detail, as is the new _addr_only.  So I am only
> testing them indirectly through the documented parts of the API (I added a
> test for <> address, and one for an IDNA encoded address).
>
> Catalin, I think you are correct about the try/except/None stuff.  As far
> as I can tell it is left over from the old days before the email package and
> its philosophy of never throwing parsing errors.  Nowadays if parseaddr
> throws an error, it is a bug.  That's a refactoring not a bug fix, though,
> so I didn't backport it.
>
> ----------
> resolution:  -> fixed
> stage: test needed -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7484>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22693/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________
-------------- next part --------------
You&#39;re very kind David.<div><br></div><div>Hope I can contribute with something more relevant next time :)</div><div><br></div><div>best regards,</div><div>Felipe<br><br><div class="gmail_quote">2011/7/18 R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><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>Thank you both for your work on this. ??The patch I committed is a combination of my _addr_only, Filipe&#39;s tests, and Catalin&#39;s modifications to those tests. ??quoteaddr, although in the __all__, is not documented and is really an implementation detail, as is the new _addr_only. ??So I am only testing them indirectly through the documented parts of the API (I added a test for &lt;&gt; address, and one for an IDNA encoded address).<br>

<br>
Catalin, I think you are correct about the try/except/None stuff. ??As far as I can tell it is left over from the old days before the email package and its philosophy of never throwing parsing errors. ??Nowadays if parseaddr throws an error, it is a bug. ??That&#39;s a refactoring not a bug fix, though, so I didn&#39;t backport it.<br>

<br>
----------<br>
resolution: ??-&gt; fixed<br>
stage: test needed -&gt; committed/rejected<br>
status: open -&gt; closed<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/issue7484" target="_blank">http://bugs.python.org/issue7484</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Tue Jul 19 04:21:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 02:21:25 +0000
Subject: [issue7484] smtplib: verify breaks with Postfix servers
In-Reply-To: <1260600956.23.0.0101749869854.issue7484@psf.upfronthosting.co.za>
Message-ID: <1311042085.49.0.725434811541.issue7484@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Don't short change yourself.  This bug would still be open if it hadn't been for your work, regardless of how much of it wound up in the final patch :)

----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7484>
_______________________________________

From report at bugs.python.org  Tue Jul 19 05:53:48 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 19 Jul 2011 03:53:48 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <CAMMy=OsUjGbpnEh1=HygOQxkf24=Dtpuz0f7UZ7NksRft9A4_w@mail.gmail.com>
Message-ID: <CAF-Rda_dSDDfBQKz3rr9akQbGo=0jj2sM+=j8WixbjFny9ziBA@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> > Therefore, I propose to change this error message to:
> >  "unicode argument expected, got '%s'"
> >  as Terry suggested.
> >
>
> Sounds good to me.
>

Terry, what are your thoughts?
Can I commit the fix?

----------
Added file: http://bugs.python.org/file22694/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________
-------------- next part --------------
<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt; Therefore, I propose to change this error message to:<br>
&gt; ??&quot;unicode argument expected, got &#39;%s&#39;&quot;<br>
&gt; ??as Terry suggested.<br>
&gt;<br>
<br>
</div>Sounds good to me.<br></blockquote><div><br>Terry, what are your thoughts?<br>Can I commit the fix?<br>??<br></div></div><br></div>

From report at bugs.python.org  Tue Jul 19 07:11:16 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 19 Jul 2011 05:11:16 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1311052276.95.0.73558622126.issue12434@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file22687/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Tue Jul 19 07:11:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 19 Jul 2011 05:11:20 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1311052280.82.0.682824279571.issue12434@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file22694/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Tue Jul 19 08:00:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 19 Jul 2011 06:00:56 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1311055256.83.0.20221926581.issue12434@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes, that would be great. It is better than my initial suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Tue Jul 19 08:21:09 2011
From: report at bugs.python.org (Petter Haggholm)
Date: Tue, 19 Jul 2011 06:21:09 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1311056469.8.0.55952042669.issue12581@psf.upfronthosting.co.za>


Petter Haggholm <petter at petterhaggholm.net> added the comment:

It?s my pleasure ? it?s very trivial, but hopefully it?ll get my feet wet and get me in a place where I am familiar enough with procedures and things to contribute something relevant. :)

Attaching a modified patch with (1) reversion to duck typing in parse.py, and (2) a few comments added to the tests. At this point, it may even be worth reviewing when someone has the time. (While the tests are pretty trivial, and admittedly coverage driven, they do hit a few edge cases with blank values &c. that were previously not run.)

----------
Added file: http://bugs.python.org/file22695/urlparsetest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Tue Jul 19 09:21:42 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Jul 2011 07:21:42 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1311060102.88.0.0709760751011.issue12581@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Petter, writing tests are ofcourse a good way to start. As long as the tests increase the coverage, those are most welcome. Thanks!

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Tue Jul 19 11:47:09 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 19 Jul 2011 09:47:09 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308864338.79.0.676975391642.issue12372@psf.upfronthosting.co.za>
Message-ID: <4E254E93.4030305@users.sourceforge.net>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hi,

sorry for the late reply.

 > STINNER Victor added the comment:
 >
> At least, I would like to know if S?bastien Sabl? (the author of the original patch) changed his opinion about this issue since 2007 ;-)

I haven't changed my mind concerning this patch and we still use it for 
the Python that we deploy on AIX 5.3 and AIX 6.1 systems (I don't use 
AIX 7 yet).

Not using this patch will result in performance degradation and 
"sem_post: Permission denied" error messages from the system popping on 
the console.

 > Charles-Fran?ois Natali added the comment:
 >
 > Well, it looks like a libc or kernel bug, and we probably can't do
 > much about it. Just falling back to mutex + condition variable instead
 > of POSIX semaphores does the trick, so I'll say just avoid POSIX
 > semaphores altogether on AIX and we should be fine. People could
 > report this to their AIX vendor, but they should definitely consider
 > dropping this terminally broken platform and switch to, let's says,
 > Linux or BSD...

I agree with Charles-Fran?ois that it is an AIX bug that should be 
reported to IBM so that they could fix it in a future release.
I already submitted some "tickets" to IBM concerning other problems and 
it is not exactly an "agile" company so you have to be very patient.

I also agree that people should consider dropping this broken platform, 
but unfortunately IBM is aggressively and successfully (AFAIK) pushing 
this platform to many customers (in the finance industry in particular) 
so I don't expect it to die soon.

regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Tue Jul 19 12:17:31 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 19 Jul 2011 10:17:31 +0000
Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1311070651.67.0.617298207572.issue12546@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I finally got around to reviewing the patch. A couple of comments:

1. There should be some tests for str.__format__, not just str.format. This is really a bug with str.__format__, after all. I can add those.

2. The bigger issue is that the other built in formatters have this same problem.

>>> format(3, '\x00<6')
'3     '
>>> format(3., '\x00<6')
'3.0   '
>>> format('3', '\x00<6')
'3\x00\x00\x00\x00\x00'
>>> format(3+1j, '\x00<6')
'(3+1j)'
[38654 refs]
>>> format(3+1j, '\x00<10')
'(3+1j)    '

I think the fix is basically the same as str.__format__ (but in format_int_or_long_internal, format_float_internal, and format_complex_internal). I tried that and it worked, but I haven't had time to write tests for them. If you (Davide) can do that, great. Otherwise I'll try and grab some time this week.

Changing the subject to match the wider scope of the problem.

----------
stage: commit review -> patch review
title: str.format cannot fill with \x00 char -> builtin __format__ methods cannot fill with \x00 char

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12546>
_______________________________________

From report at bugs.python.org  Tue Jul 19 13:29:05 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 19 Jul 2011 11:29:05 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1311074945.92.0.488222810202.issue10881@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'd like to reopen this, as it doesn't seem to be a duplicate of #8084. Specifically, test_getsitepackages in test_sitepackages appears to be wrong, since it has a correct test for platform builds later in the method, but the failure occurs earlier because the path "os.sep == '/'" is taken on OS X. The test should be restructured as e.g.

    if sys.platform in ('os2emx', 'riscos'):
        # stuff for OS/2, RISCOS
    elif (sys.platform == "darwin" and
            sysconfig.get_config_var("PYTHONFRAMEWORK")):
        # OS X platform builds
    elif os.sep == '/':
        # OS X non-platform builds, Linux, FreeBSD etc.
    else:
        # other platforms

That the test itself is broken is not the thrust of #8084.

----------
nosy: +vinay.sajip
resolution: duplicate -> 
status: closed -> open
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Jul 19 14:17:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 12:17:53 +0000
Subject: [issue12543] `issubclass(collections.deque,
	collections.Sequence) == False`
In-Reply-To: <1310498170.97.0.558143295678.issue12543@psf.upfronthosting.co.za>
Message-ID: <1311077873.4.0.372570825272.issue12543@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The sequence ABCs do not require slicing support.
Understood, but is it said in the docs?  David said that he couldn?t find that bit of info, which is why I suggested a doc bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12543>
_______________________________________

From report at bugs.python.org  Tue Jul 19 14:22:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Jul 2011 12:22:32 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1311009990.93.0.133179836732.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110719122224.GA40111@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Here is something unsorted and loose:

- @neologix:
  One could argue that something had happened before the fsync(2),
  so that code which blindly did so is too dumb to do any right
  decision anyway.  Even PEP 3151 won't help.

- I favour haypos fullsync() approach, because that could probably
  make it into it.  Yet Python doesn't offer any possibility to
  access NetBSD DISKSYNC stuff sofar.

- Currently the programmer must be aware of any platform specific
  problems.  I, for example, am not aware of Windows.  How can
  i give any guarantee to users which (will) use my S-Postman on
  Windows?  I need to put trust in turn into the Framework i am
  using - Python.  And that makes me feel pretty breathless.

- Fortunately Python is dynamic, so that one simply can replace
  os.fsync().  Works once only though (think signal handlers :=).

  + That is indeed the solution i'm using for my S-Postman,
    because *only* like this i can actually make Python's
    mailbox.py module reliable on Mac OS X!  I can't give any
    guarantee for NetBSD, though i document it!

  + Aaarrg!  I'm a liar!!  I lie about - data integrity!!!

--Steffen
Ciao, sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue Jul 19 14:32:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Jul 2011 12:32:45 +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: <20110719123234.GB40111@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

If Nir's analysis is right, and Antoines comment pushes me into
this direction, (i personally have not looked at that code),
then multiprocessing is completely brain-damaged and has been
implemented by a moron.
And yes, I know this is a bug tracker, and even that of Python.

Nir should merge his last two messages into a single mail to
python-dev, and those guys should give Nir or Thomas or a group of
persons who have time and mental power a hg(1) repo clone and
committer access to that and multiprocessing should be rewritten,
maybe even from scratch, but i dunno.

For the extremely unlikely case that all that doesn't happen maybe
the patch of neologix should make it?

--Steffen
Ciao, sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Jul 19 14:50:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jul 2011 12:50:40 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1311079840.88.0.0800142371051.issue3232@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3232>
_______________________________________

From report at bugs.python.org  Tue Jul 19 14:54:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Jul 2011 12:54:50 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <20110719123234.GB40111@sherwood.local>
Message-ID: <20110719125441.GB66534@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Um, and just to add: i'm not watching out for anything, and it won't
and it can't be me:

?0%0[steffen at sherwood sys]$ grep -F smp CHANGELOG.svn -B3 | grep -E '^r[[:digit:]]+'?| tail -n 1
r162 | steffen | 2006-01-18 18:29:58 +0100 (Wed, 18 Jan 2006) | 35 lines

--Steffen
Ciao, sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Jul 19 14:59:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 12:59:56 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1311080396.75.0.877632066602.issue12575@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/issue12575>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:01:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:01:45 +0000
Subject: [issue1602133] non-framework python fails to define os.environ
	properly
Message-ID: <1311080505.72.0.177376567027.issue1602133@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> commit review
title: non-framework built python fails to define environ properly -> non-framework python fails to define os.environ properly
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602133>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:05:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:05:59 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1311080759.9.0.489877165746.issue12524@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1. 3xx codes are as fine as 200, IIRC.

2. Agreed, Roundup as very strange form parameters and URIs in general, but that?s not something we can change.

3. Maybe the empty string would work?  (It?s a URI reference which means ?same URI as the resource where the form was found? IOW same page).


Alternate idea: use example.org.  People won?t be able to actually run the example, but is it really important?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:07:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:07:31 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311080851.64.0.256360270855.issue12583@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just a side note: please don?t use ?folder? for cross-platform code or documentation, it?s a Windows-specific term (like ?wizard? for example).

----------
nosy: +eric.araujo
title: More detailed `ImportError` messages -> More detailed ImportError messages

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:10:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:10:22 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1311081022.02.0.385384680546.issue8084@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It would be nice to have feedback from the Mac experts on this.

----------
assignee: christian.heimes -> 
keywords:  -buildbot, needs review, patch
nosy: +ned.deily
resolution: fixed -> 
stage: committed/rejected -> 
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:11:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:11:11 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1311081071.27.0.416519701443.issue10881@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

How can we detect framework builds from Python code?  Maybe there is a variable in sysconfig?

----------
nosy: +eric.araujo
superseder: pep-0370 on osx duplicates existing functionality -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:12:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:12:22 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1311081142.93.0.019531538728.issue10881@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hem, I should have re-read Vinay?s message before posting :)  Marking as easy.

----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:13:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:13:46 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1311081226.65.0.441471602479.issue7475@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7475>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:24:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:24:55 +0000
Subject: [issue12535] Chained tracebacks are confusing because the first
	traceback is minimal
In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za>
Message-ID: <1311081895.65.0.293131542147.issue12535@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/issue12535>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:26:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 13:26:04 +0000
Subject: [issue12527] assertRaisesRegex doc'd with 'msg' arg,
	but it's not implemented?
In-Reply-To: <1310315690.64.0.281773065195.issue12527@psf.upfronthosting.co.za>
Message-ID: <1311081964.26.0.654406434968.issue12527@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/issue12527>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:31:21 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 Jul 2011 13:31:21 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <1295040100.28.0.0907494738582.issue10910@psf.upfronthosting.co.za>
Message-ID: <1311082281.17.0.893063192751.issue10910@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Waiting for a new version of boost probably won't help: this is an incompatibility between a redefinition of ctypes macros in pyport.h and definitions in the C++ header <locale>.

I barely use C++ at this time and don't know how to tweak the headers to avoid this problem. It would probably have been better to not redefine the ctype.h definitions, we should have introduced Py_isascii etc. That requires some invasive changes to the Python codebase though, and I'm not sure if that is worth the trouble.

Could someone attach a sample project that suffers from this issue (with instructions on how to build it)? That would make it easier to debug the problem.

(Removing python 2.6 because that version receives only security patches at this time, adding 3.2 and 3.3 because those use the same code in pyport.h and hence should also be affected by this issue)

----------
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:33:40 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 Jul 2011 13:33:40 +0000
Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to
	<MouseWheel>
In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>
Message-ID: <1311082420.11.0.11956140677.issue10731@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is almost certainly a bug in Tk.  What OSX version are you using, and which python installer did you use?

One thing you could try is installing a matching copy of ActiveState's Tk (8.4 for the 32-bit build, 8.5 for intel-only builds of python 2.7 and 3.2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10731>
_______________________________________

From report at bugs.python.org  Tue Jul 19 15:53:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jul 2011 13:53:01 +0000
Subject: [issue12546] builtin __format__ methods cannot fill with \x00 char
In-Reply-To: <1310540286.71.0.346156272109.issue12546@psf.upfronthosting.co.za>
Message-ID: <1311083581.84.0.443758170283.issue12546@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/issue12546>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:10:42 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 19 Jul 2011 14:10:42 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1311084642.92.0.507424592536.issue10881@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This is now fixed in pythonv, see

https://bitbucket.org/vinay.sajip/pythonv/changeset/a59a3868d185/raw/pythonv-a59a3868d185.diff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:11:56 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 19 Jul 2011 14:11:56 +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: <1311084716.53.0.427020122573.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> then multiprocessing is completely brain-damaged and has been
> implemented by a moron.

Please do not use this kind of language. 
Being disrespectful to other people hurts the discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:13:57 2011
From: report at bugs.python.org (Florian Berger)
Date: Tue, 19 Jul 2011 14:13:57 +0000
Subject: [issue12585] distutils dereferences symlinks for zip but not for
	bztar/gztar target
In-Reply-To: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>
Message-ID: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>


New submission from Florian Berger <fberger at florian-berger.de>:

When creating a source distribution, formats=zip will dereference symbolic links while formats=bztar,gztar will not.

Example:

$ ls -l
drwxr-xr-x 3 4096 19. Jul 15:44 dist
-rw-r--r-- 1   53 19. Jul 15:15 foo.py
-rw-r--r-- 1   42 19. Jul 15:39 MANIFEST
-rw-r--r-- 1   42 19. Jul 15:39 MANIFEST.in
-rw-r--r-- 1  167 19. Jul 15:29 setup.py
-rw-r--r-- 1    5 19. Jul 15:16 test.dat
lrwxrwxrwx 1    8 19. Jul 15:16 test.symlink.dat -> test.dat

$ cat setup.py 
from distutils.core import setup
setup(name = 'foo',
      version = '0.1.0',
      py_modules = ['foo'],
      data_files = [("", ["test.dat", "test.symlink.dat"])])

$ python setup.py sdist --formats=gztar,zip

dist/foo-0.1.0.tar.gz does preserve the symbolic link test.symlink.dat -> test.dat, while dist/foo-0.1.0.zip does not.

This can lead to unexpected behaviour when a symlink points to a file outside the source tree. In the .zip file everything will be fine, while the .tar.* file will contain a broken link.

Actual behaviour: storing of symbolic links depends on the target format.

Expected behaviour: storing of symbolic links should not depend on the target format, i.e. format switches should be transparent. Since the zipfile module apparently does not support symbolic links, symlinks should be dereferenced for formats=gztar,bztar using the dereference=True parameter of tarfile.TarFile() in archive_util.py.

----------
assignee: tarek
components: Distutils
messages: 140669
nosy: eric.araujo, fberger, tarek
priority: normal
severity: normal
status: open
title: distutils dereferences symlinks for zip but not for bztar/gztar target
type: behavior
versions: Python 2.6, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12585>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:33:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 14:33:03 +0000
Subject: [issue12585] distutils dereferences symlinks for zip but not for
	bztar/gztar target
In-Reply-To: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>
Message-ID: <1311085983.29.0.922616032511.issue12585@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for such a good report.  Symlinks handling in distutils is under-specified; this question showed up a few months ago on the distutils-sig mailing list, with no good answer.

distutils is a special part of the standard library: as it spent a long time without dedicated maintainer, people used to rely on undocumented behavior and bugs, so when Tarek took over maintenance and started to improve and fix things, a lot of third-party code was broken.  That?s why it was decided to put distutils under a feature freeze, fixing only clear bugs, and moving efforts for new development and cleanups into the distutils2 fork (also called packaging in the Python 3.3 standard library).

Because of the fragility of distutils, we have to be careful when dealing with bug reports.  Our process is that a bug is a behavior that contradicts the documentation, otherwise it?s classified as a new feature.  For this report, I?ve found only two mentions of symlinks in the distutils docs, the first one in a support function (Doc/distutils/apiref.rst) and the second one in the docs about the MANIFEST file (Doc/distutils/sourcedist.rst).  So the only promise that the docs make is that MANIFEST entries that are symlinks are supported, but nothing is said about what will end up in the sdist.

I hope that this explanation will let you see why I?m reluctant to change distutils: we don?t know what code we will break if we improve symlink handling.  So, do you think adding a warning about symlink handling issues in the docs would be enough?

For distutils2 however, compatibility concerns do not apply yet, so we?re free to fix and document symlink handling.  If you would like to work on a patch, here are some guidelines: <http://wiki.python.org/moin/Distutils/Contributing>.  If you can?t, then thanks again for your report, which will be a good starting point.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
versions: +Python 2.7, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12585>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:53:07 2011
From: report at bugs.python.org (Florian Berger)
Date: Tue, 19 Jul 2011 14:53:07 +0000
Subject: [issue12585] distutils dereferences symlinks for zip but not for
	bztar/gztar target
In-Reply-To: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>
Message-ID: <1311087187.66.0.969711214393.issue12585@psf.upfronthosting.co.za>


Florian Berger <fberger at florian-berger.de> added the comment:

Hi,

thanks for the reply. I see your point with the legacy distutils.

> I hope that this explanation will let you see why I?m reluctant to
> change distutils: we don?t know what code we will break if we improve
> symlink handling.  So, do you think adding a warning about symlink
> handling issues in the docs would be enough?

Given the constraints, yes, it would be good to have that warning in the docs. Even better would be a runtime hint like

Notice: gztar target will preserve symbolic links.

or

Notice: zip target will dereference symbolic links.

> For distutils2 however, compatibility concerns do not apply yet,
> so we?re free to fix and document symlink handling.

That would be very welcome. I am afraid I will not be able to contribute code anytime soon, but it would be great if the regular developers could keep an eye on this inconsistency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12585>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:56:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 14:56:09 +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: <1311087369.95.0.520360269633.issue11175@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11175>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:57:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 14:57:56 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1311087476.5.0.332048740242.issue10967@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For one thing, I think resources could be implemented in terms of skips, or even included into stock unittest.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:59:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 14:59:13 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1311087553.43.0.276836784856.issue12455@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22537/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Tue Jul 19 16:59:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 14:59:19 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1311087559.82.0.315695790173.issue12455@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/issue12455>
_______________________________________

From report at bugs.python.org  Tue Jul 19 17:00:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 15:00:20 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311087620.35.0.128589561316.issue9968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Well, this is actually somewhat more complicated than what my first
> tests showed due to the way multipart/form-data is dealt with in
> FieldStorage.read_multi().
>
> The solution I proposed last time only works if the uploaded file is
> passed as the first form field.

Can you copy here the tests you did and the error output you got?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Tue Jul 19 17:08:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 15:08:43 +0000
Subject: [issue11595] Miscellaneous bugs in cfg_to_args() utility function
In-Reply-To: <1300466317.84.0.72161184259.issue11595@psf.upfronthosting.co.za>
Message-ID: <1311088123.02.0.671145336433.issue11595@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The reason being that I'm using this in my own packages so that I can
> distutils2-like setup.cfgs, but still install with normal distutils
> and/or Distribute without depending on distutils2 in its entirety.
>
> I'm wondering if there might be a better way to proceed, or if this
> sort of compatibility support is even useful to anyone else.

I think that now I understand what you meant here.  You should not have to duplicate distutils2 code in legacy setup.py scripts: ?pysetup generate-setup? will create a setup script that can find information in the setup.cfg file (so that you only have to update one file), without depending on distutils2 code (it uses inspect.getsource to copy the cfg_to_args function into setup.py).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11595>
_______________________________________

From report at bugs.python.org  Tue Jul 19 17:14:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 15:14:44 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1311088484.78.0.619742754973.issue12572@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22671/getpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Tue Jul 19 17:16:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 15:16:16 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1311088576.26.0.469224508483.issue12572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s a unified diff.

----------
Added file: http://bugs.python.org/file22696/hp-ux-compiler-workarounds.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Tue Jul 19 17:21:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 15:21:46 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1311088906.87.0.100099592388.issue12572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Arg, I thought I removed a duplicate patch but it was actually an updated version.  Sorry about that; the link in the history at the bottom of this page still links to the file.  Updated unified diff attached.

----------
Added file: http://bugs.python.org/file22697/hp-ux-compiler-workarounds.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Tue Jul 19 17:21:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 15:21:55 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1311088915.11.0.762616667988.issue12572@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22696/hp-ux-compiler-workarounds.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Tue Jul 19 17:29:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 15:29:03 +0000
Subject: [issue12572] HP/UX compiler workarounds
In-Reply-To: <1310744425.61.0.885060542603.issue12572@psf.upfronthosting.co.za>
Message-ID: <1311089343.6.0.320814796947.issue12572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Jim: Sorry if we reacted first with process remarks instead of thanking you for the patches and reviewing them.  We value contributions, and we try to be welcoming, but sometimes we forget what it?s like to enter this community.  Some things have become basic for us, like working with one unified diff instead of many context diffs, so we try to guide contributors so that their files can be easily read and fed to tools (such as code review or version control) and we can all move faster in the discussion leading to the commit.  This is not about project administration, merely common formats to make work easier for all parties involved (for example, for users generating one diff for a whole checkout is easier than generating and uploading one diff per file).

So, I hope that the diff I generated from yours will let people review it quickly, with no hurt feelings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12572>
_______________________________________

From report at bugs.python.org  Tue Jul 19 18:02:07 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 19 Jul 2011 16:02:07 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <BANLkTin5g6gL5BVm_PigiU59Hwjc=uj9RQ@mail.gmail.com>
Message-ID: <4E25AA7A.5050203@users.sourceforge.net>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Sorry for the very late reply; I have been quite busy recently with the 
birth of my second daughter, a new job, a new home town and soon a new home.

...
> But with your patch, such code wouldn't be thread-safe anymore. This
> patch implies that a thread can't call malloc directly or indirectly
> (printf, opendir, and many others) while it doesn't hold the GIL. This
> is going to break a lot of existing code.

I didn't have this problem since the threads in my application are 
handled by Python and so hold the GIL. But you are right it is a concern.

Fortunately, it is easy to solve by defining the following in dlmalloc:
#define HAVE_MORECORE 0

That way, all the memory allocations handled by Python will go in a 
dedicated mmaped memory segment controlled by dlmalloc, while all the 
calls to the system malloc will work as before (probably going into a 
segment handled by sbrk).

> It will also be slower, and consume more memory.

It should be noted that sbrk is deprecated on some platforms where mmap 
is suggested as a better replacement (Mac OS X, FreeBSD...).
sbrk is generally considered quite archaic.

I attach a new patch that can be applied to Python 2.7.1. It includes 
the dlmalloc modification and uses only mmap in this case (no sbrk).

We have delivered it in production with the new version of our software 
that works on AIX 6.1 and it works fine.

I also did some benchmarks and did not notice any slow down compared to 
a pristine Python 2.7.1 (actually it was slightly faster YMMV).
It also consumes a lot less memory, but that is the reason for this 
patch in the first place.

Since I am changing of job, I won't be working on AIX anymore (yeah!); I 
also don't expect this patch to be integrated spontaneously without 
someone interested in AIX pushing for it. So I leave this patch more as 
a reference for someone who would be impacted by this problem and would 
like to integrate it in his own Python. I hope it helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Jul 19 18:04:14 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 19 Jul 2011 16:04:14 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1311091454.96.0.885335564416.issue3526@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


Added file: http://bugs.python.org/file22698/patch_dlmalloc_Python_2_7_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Jul 19 18:04:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 16:04:50 +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: <1311091490.17.0.389543780157.issue11176@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Westley!  Do you still have time to work on this?

----------
keywords: +easy
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Tue Jul 19 18:07:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Jul 2011 16:07:54 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1311091674.25.0.34264879145.issue6818@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Martin did a review of the newer patch; maybe you didn?t get the mail (there?s a Rietveld bug when a user name without email is given to the Cc field).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6818>
_______________________________________

From report at bugs.python.org  Tue Jul 19 18:12:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jul 2011 16:12:23 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <4E25AA7A.5050203@users.sourceforge.net>
Message-ID: <1311091867.3586.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Since I am changing of job, I won't be working on AIX anymore (yeah!);

You seem happy about that :)
Does it mean the project to have an AIX buildbot is abandoned?

> I also don't expect this patch to be integrated spontaneously without 
> someone interested in AIX pushing for it. So I leave this patch more as 
> a reference for someone who would be impacted by this problem and would 
> like to integrate it in his own Python. I hope it helps.

Indeed, thanks for your contributions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Jul 19 18:22:31 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 19 Jul 2011 16:22:31 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1311092551.16.0.155455043264.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

> Does it mean the project to have an AIX buildbot is abandoned?

We have a buildbot running internally on AIX. I could not get the necessary modifications integrated upstream in the official Python buildbot so that we could plug directly on it.

cf this thread:
http://mail.python.org/pipermail/python-dev/2010-October/thread.html#104714

I will try to get someone at my company to keep this buildbot running and report any outstanding bug, but I can't guarantee anything. 

> Indeed, thanks for your contributions.

Thanks! And thank you for your help in most of the issues related to AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Jul 19 18:51:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 19 Jul 2011 16:51:10 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <1311094270.76.0.535847779555.issue12372@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Tue Jul 19 19:29:38 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 19 Jul 2011 17:29:38 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311096578.47.0.289867559676.issue12576@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

Seconded. #12133 inadvertently closes the response object if the server fails to indicate "Connection: close". In my case, Amazon S3 (s3.amazonaws.com) causes this problem:

(Python 3.2)
>>> conn = urllib.request.urlopen('http://s3.amazonaws.com/SurveyMonkeyFiles/VPAT_SurveyMonkey.pdf')
>>> len(conn.read())
27692

(Python 3.2.1)
>>> conn = urllib.request.urlopen('http://s3.amazonaws.com/SurveyMonkeyFiles/VPAT_SurveyMonkey.pdf')
>>> len(conn.read())
0

The problem is that S3 doesn't send back a "Connection: close" header, so when h.close() is called from request.py, the request object is also closed; consequently, conn.fp is None and so conn.read() returns an empty bytes object.

This is a clear regression due to the patch in #12133.

----------
nosy: +nneonneo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Tue Jul 19 19:52:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 19 Jul 2011 17:52:09 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1310719010.29.0.524397451586.issue12326@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3X-Lir_5KLvF2O6m2EMxPdPnAUPRkygQ5RVxO8mCPicQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I'm still in favor of keeping sys.platform == 'linux3', and you?
>

So do I.

> For plat-linux3, should we regenerate this directory (I cannot do that, I
> don't have Linux 3.0 yet) or can we just use a symbolic link? I read that
> Linux 3.0 doesn't break the API, so I suppose that constants are the same.
> Or can we try by copying plat-linux2 to plat-linux3?
>

I've just had a quick look, but it seems that plat-<sys.platform>
contains header definitions, so it's more function of the libc than
the kernel version. It probably makes sense on operating systems which
have a real notion of release (i.e. a consistent kernel/user-space,
like AIX or *BSD), but not so much on Linux. Copying plat-linux2 to
plat-linux3 should be just fine.

Your patch looks fine to me, except for this:
-        if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
-                        'freebsd7', 'freebsd8')
-            or platform.startswith("gnukfreebsd")):
+        if os.uname()[0] in ('Linux', 'FreeBSD'):

Why not use platform.system(), to be consistent?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Jul 19 20:04:50 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Tue, 19 Jul 2011 18:04:50 +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: <1311098690.15.0.889110973467.issue11176@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

I worked on this some time ago; the problem was the size of the documentation, i.e. it was difficult to stay consistent.  Do I have time for this?  Yes, but I wouldn't get it done anytime soon, and the results could be anywhere from good to bad.  As it stands, the documentation is fairly good, so I don't think it's imperative to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Tue Jul 19 20:21:18 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Jul 2011 18:21:18 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311099678.56.0.27484033667.issue12583@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Doing a stack walk to try to determine if an import failure was from a circular import would be costly, a little complicated (since you cannot simply look at import statements but also various kinds of functions that can do an equivalent job of importing) and probably not worth it.

As for ImportWarning, it's at least mentioned in the exception hierarchy and the warnings docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Tue Jul 19 20:24:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 18:24:21 +0000
Subject: [issue12586] Enhanced email API: header objects
In-Reply-To: <1311099861.14.0.161435767608.issue12586@psf.upfronthosting.co.za>
Message-ID: <1311099861.14.0.161435767608.issue12586@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The work I've been doing on email6 has reached a stage where I'm confident about the overall plan of the new code, and am ready for people to review it and make suggestions.  The patch represents a working state of the code, but with several omissions that I will continue to work on while the rest of the code is reviewed.  The major omissions are that address headers don't yet handle encoded words in their 'value' and related attributes, and that structured headers do not properly support unicode characters when the message is flattened.  (The traditional email5 methods for handling unicode in structured headers still work fine, though).  There are also edge-cases where the address parser does not do as well as email.utils.parseaddr (and other cases where it does better).

A goal of email6 is to be 100% backward compatible with the existing email5.1 API.  If you find any deviations please let me know.

A new policy, email6_defaults, allows you to run the code with what are intended to be the defaults in Python 3.4.  (Not specifying either email6_defaults or email5_defaults when creating a message will result in warning messages in cases where it would make a difference which policy was in force).  The only difference between the two right now is that email6_defaults sets 'use_decoded' true, which means that the string value of header objects is the fully unicode version, not the ASCII-only version that comes from the source as is true with email5_defaults.

I've also released this version of the code as email-6.0.0a1 on pypi, so that it can be tested using 3.2 (you import it as 'email6').

I will separately attach here the README from the pypi package, which details the header features that are finished and the ones that still need work.

After review, I'd like to go ahead and check this in to default and continue the work from there.  From this point until I start work on the message_factory all changes will be incremental.  When we originally planned out email6 we thought we'd be making a "compatibility break" with backward compatibility shims.  As things have turned out the work is more a matter of incremental improvement of the API while maintaining the old API, and thus it seems reasonable to me to work on it directly in default rather than continue to work on it in a separate feature branch.

If, that is, the approach here is accepted :)  The email-sig seems to like it.

Oh, yeah, and there's room for plenty of bike-shedding about certain attribute names &c.

----------
assignee: r.david.murray
components: Library (Lib)
hgrepos: 44
messages: 140687
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Enhanced email API: header objects
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12586>
_______________________________________

From report at bugs.python.org  Tue Jul 19 20:25:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 18:25:23 +0000
Subject: [issue12586] Enhanced email API: header objects
In-Reply-To: <1311099861.14.0.161435767608.issue12586@psf.upfronthosting.co.za>
Message-ID: <1311099923.66.0.378249736573.issue12586@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22699/b22698463737.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12586>
_______________________________________

From report at bugs.python.org  Tue Jul 19 20:26:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jul 2011 18:26:48 +0000
Subject: [issue12586] Enhanced email API: header objects
In-Reply-To: <1311099861.14.0.161435767608.issue12586@psf.upfronthosting.co.za>
Message-ID: <1311100008.21.0.0445434293323.issue12586@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file22700/README.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12586>
_______________________________________

From report at bugs.python.org  Tue Jul 19 20:49:11 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 19 Jul 2011 18:49:11 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311101351.71.0.0963008153323.issue12583@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Tue Jul 19 20:54:13 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Jul 2011 18:54:13 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1311101653.51.0.202667568859.issue10309@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm running into this while trying to backport Python 2.7.2 to Ubuntu 10.04.  Our build machines are throwing an error because they catch the implicit cast so as to prevent problems on ia64 and amd64.

http://wiki.debian.org/IMplicitPointerConversions

I haven't quite gotten the patch to work yet, but when I do, I'll look at applying this patch upstream as well.

----------
nosy: +barry
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10309>
_______________________________________

From report at bugs.python.org  Tue Jul 19 21:02:50 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Jul 2011 19:02:50 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1311102170.95.0.528987737353.issue10309@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
assignee: theller -> 
nosy:  -theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10309>
_______________________________________

From report at bugs.python.org  Tue Jul 19 21:04:52 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Jul 2011 19:04:52 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <20110719123234.GB40111@sherwood.local>
Message-ID: <20110719190438.GA81657@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

P.S.:
I have to apologize, it's Toma?, not Thomas.
(And unless i'm mistaken this is pronounced "TomAsch" rather than
the english "Tommes", so i was just plain wrong.)

--Steffen
Ciao, sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Jul 19 21:07:07 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Jul 2011 19:07:07 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1311102427.43.0.25660774049.issue10309@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10309>
_______________________________________

From report at bugs.python.org  Tue Jul 19 21:14:29 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 19 Jul 2011 19:14:29 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1311084716.53.0.427020122573.issue6721@psf.upfronthosting.co.za>
Message-ID: <20110719191419.GA81686@nothing>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> > then multiprocessing is completely brain-damaged and has been
> > implemented by a moron.
> 
> Please do not use this kind of language. 
> Being disrespectful to other people hurts the discussion.

So i apologize once again.
'Still i think this should go to python-dev in the mentioned case.

(BTW: there are religions without "god", so whom shall e.g. i praise
for the GIL?)

--Steffen
Ciao, sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Jul 19 21:45:05 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 19 Jul 2011 19:45:05 +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: <1311104705.37.0.540930836793.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

> (BTW: there are religions without "god", so whom shall e.g. i praise for the GIL?)

Guido? ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue Jul 19 22:20:30 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 19 Jul 2011 20:20:30 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311106830.04.0.225174566855.issue12583@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Brett: Why does it matter that it will be costly? It's a post-mortem activity anyway, usually done when something critical failed and the entire system isn't working.

Why would functions need to be looked at? I mean, isn't a circular import when you try to import a module `foo` while in a lower stack level you haven't finished importing `foo` yet? Does it get trickier than that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Tue Jul 19 22:23:42 2011
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 19 Jul 2011 20:23:42 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311107022.18.0.763367522139.issue12583@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Brett, I checked out the two pieces of documentation you referred to, they have very little information about ImportWarning other than "Base class for warnings about probable mistakes in module imports."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Tue Jul 19 23:19:00 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 19 Jul 2011 21:19:00 +0000
Subject: [issue12587]
	tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a
	UTF8 BOM signature
In-Reply-To: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>
Message-ID: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

>From a fresh Python3.2.1 tarball:

nneonneo at nneonneo-mbp:~/devel/Python-3.2.1/Lib/test$ for i in tokenize_tests-*; do echo $i; xxd $i | head -n 1; done
tokenize_tests-latin1-coding-cookie-and-utf8-bom-sig.txt
0000000: efbb bf23 202d 2a2d 2063 6f64 696e 673a  ...# -*- coding:
tokenize_tests-no-coding-cookie-and-utf8-bom-sig-only.txt
0000000: efbb bf23 2049 4d50 4f52 5441 4e54 3a20  ...# IMPORTANT: 
tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt
0000000: efbb bf23 202d 2a2d 2063 6f64 696e 673a  ...# -*- coding:
tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt
0000000: efbb bf23 202d 2a2d 2063 6f64 696e 673a  ...# -*- coding:

>From this, it appears that the file called "tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt" actually has a UTF-8 BOM signature, which means either the comment is lying or the BOM was accidentally added to the test file at some point.

----------
messages: 140694
nosy: nneonneo
priority: normal
severity: normal
status: open
title: tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a UTF8 BOM signature
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12587>
_______________________________________

From report at bugs.python.org  Tue Jul 19 23:26:19 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Jul 2011 21:26:19 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1311110779.36.0.422616737195.issue10309@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Python 3.1 is in security only mode, so this patch cannot be applied to that version.

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10309>
_______________________________________

From report at bugs.python.org  Tue Jul 19 23:36:41 2011
From: report at bugs.python.org (rpointel)
Date: Tue, 19 Jul 2011 21:36:41 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hello,
the test test_subinterps failed on OpenBSD on powerpc architecture.
It works fine on amd64 and sparc64.
(The test_pendingcalls_threaded has been skipped because it blocks on OpenBSD).

Don't hesitate if you need more informations.
Details:

Re-running test 'test_capi' in verbose mode
test_instancemethod (test.test_capi.CAPITest) ... ok
test_memoryview_from_NULL_pointer (test.test_capi.CAPITest) ... ok
test_no_FatalError_infinite_loop (test.test_capi.CAPITest) ... ok
test_pendingcalls_non_threaded (test.test_capi.TestPendingCalls) ... ok
test_pendingcalls_threaded (test.test_capi.TestPendingCalls) ... skipped 'blocking on OpenBSD'
test (test.test_capi.Test6012) ... ok
test_subinterps (test.test_capi.EmbeddingTest) ... test test_capi failed
FAIL

======================================================================
FAIL: test_subinterps (test.test_capi.EmbeddingTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/test_capi.py", line 170, in test_subinterps
    (p.returncode, err))
AssertionError: -11 != 0 : bad returncode -11, stderr is b''

----------------------------------------------------------------------
Ran 7 tests in 3.797s

FAILED (failures=1, skipped=1)

----------
components: Tests
messages: 140696
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_capi.test_subinterps() failed on OpenBSD (powerpc)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Tue Jul 19 23:40:34 2011
From: report at bugs.python.org (rpointel)
Date: Tue, 19 Jul 2011 21:40:34 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hello,
the test test_nan_inf failed on OpenBSD on powerpc architecture.
It works fine on amd64 and sparc64.

Don't hesitate if you need more informations.
Details:

Re-running test 'test_long' in verbose mode
test__format__ (test.test_long.LongTest) ... ok
test_bit_length (test.test_long.LongTest) ... ok
test_bitop_identities (test.test_long.LongTest) ... ok
test_conversion (test.test_long.LongTest) ... ok
test_correctly_rounded_true_division (test.test_long.LongTest) ... ok
test_division (test.test_long.LongTest) ... ok
test_float_conversion (test.test_long.LongTest) ... ok
test_float_overflow (test.test_long.LongTest) ... ok
test_format (test.test_long.LongTest) ... ok
test_from_bytes (test.test_long.LongTest) ... ok
test_karatsuba (test.test_long.LongTest) ... ok
test_logs (test.test_long.LongTest) ... ok
test_long (test.test_long.LongTest) ... ok
test_mixed_compares (test.test_long.LongTest) ... ok
test_nan_inf (test.test_long.LongTest) ... FAIL
test_round (test.test_long.LongTest) ... ok
test_small_ints (test.test_long.LongTest) ... ok
test_to_bytes (test.test_long.LongTest) ... ok
test_true_division (test.test_long.LongTest) ... /usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/regrtest.py:1053: ResourceWarning: unclosed <socket.socket object, fd=11, family=2, type=1, proto=0>
  gc.collect()
/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/regrtest.py:1053: ResourceWarning: unclosed <socket.socket object, fd=12, family=2, type=1, proto=0>
  gc.collect()
/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/regrtest.py:1053: ResourceWarning: unclosed <socket.socket object, fd=13, family=2, type=1, proto=0>
  gc.collect()
test test_long failed
ok

======================================================================
FAIL: test_nan_inf (test.test_long.LongTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/obj/ports/Python-3.2.1/Python-3.2.1/Lib/test/test_long.py", line 633, in test_nan_inf
    self.assertRaises(OverflowError, int, float('inf'))
AssertionError: OverflowError not raised by int

----------------------------------------------------------------------
Ran 19 tests in 25.020s

FAILED (failures=1)

----------
components: Tests
messages: 140697
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_long.test_nan_inf() failed on OpenBSD (powerpc)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Tue Jul 19 23:50:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jul 2011 21:50:30 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311112230.88.0.357882770919.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What is the result of int(float('inf')) ?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:04:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Jul 2011 22:04:35 +0000
Subject: [issue12587]
	tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a
	UTF8 BOM signature
In-Reply-To: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>
Message-ID: <1311113075.62.0.753951671475.issue12587@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It looks like a BOM has been present in that file for a *long* time: it is there in the Python 3.0 source tarball, and, according to the converted svn-to-hg history, it was there in its original check-in and is still there in the current development tip.

----------
nosy: +ned.deily, trent
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12587>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:29:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jul 2011 22:29:46 +0000
Subject: [issue12571] Python built on Linux 3.0 doesn't include DLFCN
In-Reply-To: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>
Message-ID: <E1QjInR-0006dS-1s@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 69dd70e70cc8 by Antoine Pitrou in branch '2.7':
Issue #12571: Add a plat-linux3 directory mirroring the plat-linux2 directory,
http://hg.python.org/cpython/rev/69dd70e70cc8

New changeset 9e3b28a7898f by Antoine Pitrou in branch '3.2':
Issue #12571: Add a plat-linux3 directory mirroring the plat-linux2 directory,
http://hg.python.org/cpython/rev/9e3b28a7898f

New changeset 0c52098a13c6 by Antoine Pitrou in branch 'default':
Issue #12571: Add a plat-linux3 directory mirroring the plat-linux2 directory,
http://hg.python.org/cpython/rev/0c52098a13c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12571>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:30:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jul 2011 22:30:22 +0000
Subject: [issue12571] Python built on Linux 3.0 doesn't include DLFCN
In-Reply-To: <1310715370.45.0.338132318055.issue12571@psf.upfronthosting.co.za>
Message-ID: <1311114622.24.0.298639041038.issue12571@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12571>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:34:02 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 19 Jul 2011 22:34:02 +0000
Subject: [issue12587]
	tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a
	UTF8 BOM signature
In-Reply-To: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>
Message-ID: <1311114842.05.0.411325658171.issue12587@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

Yes, it seems that way. Then the question is: why does the comment claim that it doesn't have a BOM?

Also, test_tokenize.py is wrong around line 651:

    def test_utf8_coding_cookie_and_no_utf8_bom(self):
        f = 'tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt'
        self.assertTrue(self._testFile(f))

It reads the wrong file in this case, judging by the testcase name. (This makes it a duplicate of the test_utf8_coding_cookie_and_utf8_bom case)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12587>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:40:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jul 2011 22:40:59 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <CAH_1eM3X-Lir_5KLvF2O6m2EMxPdPnAUPRkygQ5RVxO8mCPicQ@mail.gmail.com>
Message-ID: <1311115180.3618.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Copying plat-linux2 to plat-linux3 should be just fine.

Done in issue12571.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:41:18 2011
From: report at bugs.python.org (Robert Xiao)
Date: Tue, 19 Jul 2011 22:41:18 +0000
Subject: [issue12587]
	tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a
	UTF8 BOM signature
In-Reply-To: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>
Message-ID: <1311115278.83.0.494553858983.issue12587@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

Attached is a patch which fixes this. Python 3.2.1 still passes the test after applying the patch, as expected.

----------
keywords: +patch
Added file: http://bugs.python.org/file22701/issue12587.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12587>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:46:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jul 2011 22:46:06 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311115566.07.0.452747261148.issue12588@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

test_subinterps merely runs ./Modules/_testembed, so perhaps you could launch it manually and see what it does?
(chances are it crashes, then can you please post the backtrace using a debugger?)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Wed Jul 20 00:53:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jul 2011 22:53:03 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <1311115983.0.0.269680381253.issue12372@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch looks fine to me.

> in the finance industry in particular

Ha, I've seen that. There are even proprietary desktop applications for AIX!

----------
stage: patch review -> commit review
type:  -> behavior
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Wed Jul 20 01:19:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jul 2011 23:19:08 +0000
Subject: [issue12587]
	tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a
	UTF8 BOM signature
In-Reply-To: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>
Message-ID: <E1QjJZC-0001dn-W1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0c254698e0ed by Ned Deily in branch '3.2':
Issue #12587: Correct faulty test file and reference in test_tokenize.
http://hg.python.org/cpython/rev/0c254698e0ed

New changeset c1d2b6b337c5 by Ned Deily in branch 'default':
Issue #12587: Correct faulty test file and reference in test_tokenize.
http://hg.python.org/cpython/rev/c1d2b6b337c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12587>
_______________________________________

From report at bugs.python.org  Wed Jul 20 01:20:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Jul 2011 23:20:35 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <CAH_1eM3X-Lir_5KLvF2O6m2EMxPdPnAUPRkygQ5RVxO8mCPicQ@mail.gmail.com>
Message-ID: <201107200119.38808.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Your patch looks fine to me, except for this:
> -        if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
> -                        'freebsd7', 'freebsd8')
> -            or platform.startswith("gnukfreebsd")):
> +        if os.uname()[0] in ('Linux', 'FreeBSD'):
> 
> Why not use platform.system(), to be consistent?

I'm not sure that thp platform module can be used in setup.py 
(bootstrap issue?). It should be tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jul 20 01:21:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Jul 2011 23:21:48 +0000
Subject: [issue12587]
	tokenize_tests-utf8-coding-cookie-and-no-utf8-bom-sig.txt has a
	UTF8 BOM signature
In-Reply-To: <1311110340.06.0.59907930521.issue12587@psf.upfronthosting.co.za>
Message-ID: <1311117708.55.0.534126407571.issue12587@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report and the patch!  Applied to 3.2 (for 3.2.2) and default (for 3.3).

----------
assignee:  -> ned.deily
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12587>
_______________________________________

From report at bugs.python.org  Wed Jul 20 01:26:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Jul 2011 23:26:16 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <201107200119.38808.victor.stinner@haypocalc.com>
Message-ID: <1311117894.3618.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 19 juillet 2011 ? 23:20 +0000, STINNER Victor a ?crit :
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> > Your patch looks fine to me, except for this:
> > -        if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
> > -                        'freebsd7', 'freebsd8')
> > -            or platform.startswith("gnukfreebsd")):
> > +        if os.uname()[0] in ('Linux', 'FreeBSD'):
> > 
> > Why not use platform.system(), to be consistent?
> 
> I'm not sure that thp platform module can be used in setup.py 
> (bootstrap issue?). It should be tested.

Why don't you just use platform.startswith? It would avoid introducing
bugs due to subtle differences between uname, platform or
platform.system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Jul 20 01:28:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Jul 2011 23:28:38 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <E1QjJiO-0002Ja-QC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8f3cc8ffc3ff by Barry Warsaw in branch '2.7':
- Issue #10309: Define _GNU_SOURCE so that mremap() gets the proper
http://hg.python.org/cpython/rev/8f3cc8ffc3ff

New changeset cc00e09404e6 by Barry Warsaw in branch '3.2':
- Issue #10309: Define _GNU_SOURCE so that mremap() gets the proper
http://hg.python.org/cpython/rev/cc00e09404e6

New changeset 9986fff720a2 by Barry Warsaw in branch 'default':
- Issue #10309: Define _GNU_SOURCE so that mremap() gets the proper
http://hg.python.org/cpython/rev/9986fff720a2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10309>
_______________________________________

From report at bugs.python.org  Wed Jul 20 01:30:37 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Jul 2011 23:30:37 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1311118237.8.0.492692451316.issue10309@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10309>
_______________________________________

From senthil at uthcode.com  Wed Jul 20 02:06:20 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 20 Jul 2011 08:06:20 +0800
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1311080759.9.0.489877165746.issue12524@psf.upfronthosting.co.za>
References: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
	<1311080759.9.0.489877165746.issue12524@psf.upfronthosting.co.za>
Message-ID: <20110720000620.GA2804@mathmagic>

Hello Eric,

On Tue, Jul 19, 2011 at 01:05:59PM +0000, ?ric Araujo wrote:

> Alternate idea: use example.org.  People won?t be able to actually
> run the example, but is it really important?

The whole idea is present a usable example. Please don't suggest
unusable example. example.org does not support POST.


From report at bugs.python.org  Wed Jul 20 02:06:30 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Jul 2011 00:06:30 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1311080759.9.0.489877165746.issue12524@psf.upfronthosting.co.za>
Message-ID: <20110720000620.GA2804@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hello Eric,

On Tue, Jul 19, 2011 at 01:05:59PM +0000, ?ric Araujo wrote:

> Alternate idea: use example.org.  People won?t be able to actually
> run the example, but is it really important?

The whole idea is present a usable example. Please don't suggest
unusable example. example.org does not support POST.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 20 03:20:21 2011
From: report at bugs.python.org (Miguel Luis)
Date: Wed, 20 Jul 2011 01:20:21 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1311124821.08.0.592154438857.issue10141@psf.upfronthosting.co.za>


Changes by Miguel Luis <mkxpto at gmail.com>:


----------
nosy: +mluis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Wed Jul 20 03:33:10 2011
From: report at bugs.python.org (=?utf-8?q?Tiago_Gon=C3=A7alves?=)
Date: Wed, 20 Jul 2011 01:33:10 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1311125590.66.0.0933239055495.issue10141@psf.upfronthosting.co.za>


Tiago Gon?alves <tiagogoncalves at ua.pt> added the comment:

This patch should be easy to verify and includes documentation and the test cases.

ogait87 at mypc:~/cpython$ hg sum
parent: 71435:6f9d917df541 tip
 Fix test_multiprocessing failure under Windows.
branch: default
commit: 7 modified
update: (current)

----------
keywords: +patch
Added file: http://bugs.python.org/file22702/socketcan.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Wed Jul 20 04:02:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 02:02:46 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311127366.03.0.149187223983.issue12583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, there are ways other than an import statement that a module can get imported (the __import__ function, for example, and the imp module for another, as well as importlib).

If you want to try your hand at writing a patch to do the post mortem you will discover that import in Python is...complicated.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Wed Jul 20 04:07:31 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Wed, 20 Jul 2011 02:07:31 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1311127651.08.0.375683469827.issue12545@psf.upfronthosting.co.za>


Kuberan Naganathan <kubiyak at gmail.com> added the comment:

Hi.  I can submit a patch for the first part.  Should I submit on this issue tracker item?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 20 05:12:21 2011
From: report at bugs.python.org (Simon Forman)
Date: Wed, 20 Jul 2011 03:12:21 +0000
Subject: [issue12590] First line and cursor not visible when opening files
In-Reply-To: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>
Message-ID: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>


New submission from Simon Forman <forman.simon at gmail.com>:

In IDLE if you open a file that is longer than the editor window the first line, with the cursor, is scrolled off the top of the window making it appear as though the file begins at the second line.

This can be fixed by adding 'text.see("insert")' to the end of the EditorWindow __init__() method, but see Bruce Sherwood's comment on http://bugs.python.org/issue10079#msg118618

----------
components: IDLE
messages: 140716
nosy: sforman
priority: normal
severity: normal
status: open
title: First line and cursor not visible when opening files
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12590>
_______________________________________

From report at bugs.python.org  Wed Jul 20 05:16:13 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Jul 2011 03:16:13 +0000
Subject: [issue12590] First line and cursor not visible when opening files
In-Reply-To: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>
Message-ID: <1311131773.99.0.451215661456.issue12590@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ned.deily
nosy: +ned.deily
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12590>
_______________________________________

From report at bugs.python.org  Wed Jul 20 05:25:10 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 20 Jul 2011 03:25:10 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311132310.63.0.0469254486656.issue12531@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Peter, would you like to submit a corrected patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Wed Jul 20 05:47:58 2011
From: report at bugs.python.org (Nasos Dousis)
Date: Wed, 20 Jul 2011 03:47:58 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <1311082281.17.0.893063192751.issue10910@psf.upfronthosting.co.za>
Message-ID: <CABPhvm=oJWoV47wp_faS6jiXqx6zQr2hZTzS8ME6dUdegNaZsQ@mail.gmail.com>


Nasos Dousis <ndousis at gmail.com> added the comment:

Ronald, thanks again. ?I stripped out as much as I could from the
original code and generated the attached project.  In doing so, I
narrowed the problem down to boost/weak_ptr.hpp.

The sample project consists of:

test-boost-python/Makefile
test-boost-python/src
test-boost-python/src/Jamroot
test-boost-python/src/test
test-boost-python/src/test/Jamfile
test-boost-python/src/test/TestBoostPython.cc
test-boost-python/src/test/TestBoostPython.hh
test-boost-python/tools/Makefile

Before building the project (just type "make" in test-boost-python),
you'll need to download Boost and save it to
test-boost-python/tools/boost/boost.tar.bz2; also, the tools/Makefile
automatically downloads Python 2.7.2, but you can try Python 3.2+ in
its place.

Thanks and kind regards,
Nasos

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Wed Jul 20 05:49:00 2011
From: report at bugs.python.org (Nasos Dousis)
Date: Wed, 20 Jul 2011 03:49:00 +0000
Subject: [issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++
	compilation
In-Reply-To: <CABPhvm=oJWoV47wp_faS6jiXqx6zQr2hZTzS8ME6dUdegNaZsQ@mail.gmail.com>
Message-ID: <CABPhvm=0Ud7cpYNa3e2OuwOPN1DbN=eJNAm6kSeBYqG6XwPfqw@mail.gmail.com>


Nasos Dousis <ndousis at gmail.com> added the comment:

With attachment--

----------
Added file: http://bugs.python.org/file22703/test-boost-python.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-boost-python.tar.gz
Type: application/x-gzip
Size: 2111 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20110720/311aae55/attachment-0001.bin>

From report at bugs.python.org  Wed Jul 20 07:24:37 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 20 Jul 2011 05:24:37 +0000
Subject: [issue12591] configparser can't read_file the output of
	subprocess.Popen
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

>>> a = subprocess.Popen(['cat', '/path/to/text.ini'], stdout=subprocess.PIPE, universal_newlines=True)
>>> b = configparser.ConfigParser()
>>> b.read_file(a.stdout)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/hostname/sig/local/lib/python3.2/configparser.py", line 708, in read_file
    self._read(f, source)
  File "/hostname/sig/local/lib/python3.2/configparser.py", line 994, in _read
    for lineno, line in enumerate(fp, start=1):
AttributeError: '_io.FileIO' object has no attribute 'read1'

Also this fails without universal_readlines, which is not so bad except that the name 'read_file' doesn't exactly indicate this.

I found one mildly related bug: http://bugs.python.org/issue11670

----------
components: IO, Interpreter Core, Library (Lib)
messages: 140720
nosy: anacrolix
priority: normal
severity: normal
status: open
title: configparser can't read_file the output of subprocess.Popen
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Wed Jul 20 08:46:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 20 Jul 2011 06:46:46 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1311127651.08.0.375683469827.issue12545@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3KHLXaJgR-RTNtBfJwwyvV6qMMsqYyVEyAcipSUyzW8g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Hi. ?I can submit a patch for the first part. ?Should I submit on this issue tracker item?
>

Sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 20 09:29:55 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 20 Jul 2011 07:29:55 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311146995.44.0.0399538854067.issue12583@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

David, I don't think you've read my message carefully enough. I'm well aware that there are other ways in Python to import than the `import` statement. I'm proposing that it doesn't matter.

I asked, "isn't a circular import when you try to import a module `foo` while in a lower stack level you haven't finished importing `foo` yet?" If this is true, then you just need to have some kind of flag for each module saying "This module is currently being imported", which you set to `True` when you start importing and back to `False` when you finished importing. (It doesn't have to look exactly like this, it could be a context manager, or alternatively a centralized list of all module that are currently in the middle of an import.) Then when you have an `ImportError`, you check whether the module that the user tried to import has that flag raised, and if so notify him that it's probably a circular import problem.

Will that work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Wed Jul 20 09:55:45 2011
From: report at bugs.python.org (Bharadwaj)
Date: Wed, 20 Jul 2011 07:55:45 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1311148545.23.0.0738316493047.issue12524@psf.upfronthosting.co.za>


Changes by Bharadwaj <barbi.bruce at gmail.com>:


Added file: http://bugs.python.org/file22704/http_example2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 20 10:18:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Jul 2011 08:18:46 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1311149926.15.0.754151765935.issue12545@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> So I'd suggest forgetting about this part.

If someone really wants this feature (relative seek of more than 2^63), he/she should open a new issue.

This issue remembers me a mktime() issue: mktime() may return -1 even if it is not an error. time_mktime() uses now a sentinel to detect an error:

    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 succeeded. */
    if (tt == (time_t)(-1) && buf.tm_wday == -1) /* OverflowError */

For lseek, we can rely on errno. Try something like that:

errno = 0;
offset = lseek(...);
if (offset == (off_t)-1 && errno) /* error */

We can write a test using a sparse file... Or maybe a mmap object?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Wed Jul 20 10:56:21 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 20 Jul 2011 08:56:21 +0000
Subject: [issue12592] modify configure.in to detect OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hi,
I tested to build Python 2.7 and Python 3.2.1 (it would be the same with others versions of Python) and it failed to build on OpenBSD 5.0 (beta version).

This is the diff to correctly work on OpenBSD 5.x:

--- configure.in.orig   Sat Jul  9 08:58:56 2011
+++ configure.in        Wed Jul 20 10:19:37 2011
@@ -320,7 +320,7 @@
     # As this has a different meaning on Linux, only define it on OpenBSD
     AC_DEFINE(_BSD_SOURCE, 1, [Define on OpenBSD to activate all library features])
     ;;
-  OpenBSD/4.@<:@789@:>@)
+  OpenBSD/4.@<:@789@:>@ | OpenBSD/5.*)
     # OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is
     # also defined. This can be overridden by defining _BSD_SOURCE
     # As this has a different meaning on Linux, only define it on OpenBSD

Could you add this modification in the different versions of Python ?

Thanks a lot,

Remi.

----------
components: Installation
messages: 140724
nosy: rpointel
priority: normal
severity: normal
status: open
title: modify configure.in to detect OpenBSD 5.x
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12592>
_______________________________________

From report at bugs.python.org  Wed Jul 20 11:04:20 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 20 Jul 2011 09:04:20 +0000
Subject: [issue12593] define OpenBSD in configure.in if Py_ENABLE_SHARED == 1
In-Reply-To: <1311152659.95.0.347600213537.issue12593@psf.upfronthosting.co.za>
Message-ID: <1311152659.95.0.347600213537.issue12593@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hi,

Could you define OpenBSD in enable_shared section of the configure.in ?

I just tested with Python 3.2.1, but it could be usefull to add it in the other versions of Python 3.x.

This is the diff which seems to work :

--- configure.in.orig   Sat Jul  9 08:58:56 2011
+++ configure.in        Wed Jul 20 10:19:37 2011
@@ -755,7 +755,7 @@
              PY3LIBRARY=libpython3.so
          fi
           ;;
-    Linux*|GNU*|NetBSD*|FreeBSD*|DragonFly*)
+    Linux*|GNU*|NetBSD*|FreeBSD*|OpenBSD*|DragonFly*)
          LDLIBRARY='libpython$(LDVERSION).so'
          BLDLIBRARY='-L. -lpython$(LDVERSION)'
          RUNSHARED=LD_LIBRARY_PATH=`pwd`:${LD_LIBRARY_PATH}

Thanks a lot,

Remi.

----------
components: Installation
messages: 140725
nosy: rpointel
priority: normal
severity: normal
status: open
title: define OpenBSD in configure.in if Py_ENABLE_SHARED == 1
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12593>
_______________________________________

From report at bugs.python.org  Wed Jul 20 14:06:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 12:06:43 +0000
Subject: [issue12591] text files returned by subprocess.Popen with
	universal_newlines=True are not iterable
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311163603.33.0.445786899589.issue12591@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This isn't a problem with ConfigParser, it's a problem with the text file object returned by Subprocess.  You can reproduce the bug by trying to iterate over the TextIOWrapper returned by subprocess.

(It is true, however, that the ConfigParser docs should be specific that it isn't "any file", but "any text file".  If you would like to open a separate issue about that, that would be great).

----------
nosy: +gregory.p.smith, haypo, lukasz.langa, pitrou, r.david.murray
stage:  -> needs patch
title: configparser can't read_file the output of subprocess.Popen -> text files returned by subprocess.Popen with universal_newlines=True are not iterable
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Wed Jul 20 14:22:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 12:22:03 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311164523.87.0.612794774622.issue12583@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It might.  Although I did miss your message about the flag, my point really was that you'll find that import is very complicated when you try to write the patch to do it.  There may not be one central place you can set and query that flag, because of the various ways import can happen and the byzantine nature of the import code.  It doesn't seem likely that anyone on the current team is going to tackle tying this, but you are welcome to.  We always need more contributors.  Just bear in mind that we weigh the benefits of patches against the additional code complexity they introduce (if they do; the most fortunate patches simplify things).  I think that's what Brett meant by "probably not worth it".

Brett wrote importlib to move a lot of the complication into Python code where it would be easier to work with.  That transition hasn't happened yet.  I hear that the import-sig is talking about doing some interesting things to (hopefully) make life better for everyone, so you might want to sign on there and find out what is going on before starting on a patch.

----------
priority: normal -> low
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Wed Jul 20 14:24:10 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Jul 2011 12:24:10 +0000
Subject: [issue12593] define OpenBSD in configure.in if Py_ENABLE_SHARED == 1
In-Reply-To: <1311152659.95.0.347600213537.issue12593@psf.upfronthosting.co.za>
Message-ID: <1311164650.5.0.21996776518.issue12593@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This is a duplicate of #12560.

----------
nosy: +skrah
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> libpython.so not built on OpenBSD
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12593>
_______________________________________

From report at bugs.python.org  Wed Jul 20 14:24:18 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Jul 2011 12:24:18 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1311164658.32.0.963294995301.issue12560@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +rpointel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Wed Jul 20 15:48:04 2011
From: report at bugs.python.org (Austin Bingham)
Date: Wed, 20 Jul 2011 13:48:04 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311169684.88.0.320480849896.issue7897@psf.upfronthosting.co.za>


Austin Bingham <austin.bingham at gmail.com> added the comment:

Has a decision been made to implement some form of parametric tests? Is working being done?

Along with parameterizing individual test methods, I'd also like to throw out a request for parametric TestCases. In some cases I find that I want the behavior of setUp() or tearDown() to vary based on some set of parameters, but the individual tests are not parametric per se.

----------
nosy: +abingham

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 15:54:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 20 Jul 2011 13:54:40 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311170080.77.0.224652129875.issue7897@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

By this issue existing, that's the decision that we should probably do this, and I think the discussion shows we agree it should happen. How it's done is another way, and we have roughly a year to get it figured out before 3.3 gets closer.

I have a patch that implements this as a decorator, but it's out of date by now and not feature complete. It's on my todo list of patches to revive.

----------
components: +Tests
stage:  -> needs patch
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 15:59:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 13:59:27 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311170367.86.0.0140733733965.issue7897@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/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:02:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jul 2011 14:02:52 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <E1QjXMQ-00081h-VT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ab4d403cb0c0 by Senthil Kumaran in branch '3.2':
Fix closes issue12524 - update http.client POST example with a working example.
http://hg.python.org/cpython/rev/ab4d403cb0c0

New changeset bc71fff2b6c7 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes issue12524 - update http.client POST example with a working example.
http://hg.python.org/cpython/rev/bc71fff2b6c7

New changeset b754641a429f by Senthil Kumaran in branch '2.7':
merge from 3.2 - Fix closes issue12524 - update http.client POST example with a working example. - Patch contributed by Bharadwaj
http://hg.python.org/cpython/rev/b754641a429f

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:03:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 14:03:22 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311170602.01.0.108817720696.issue7897@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Brian, if you don't have time to work on it in the next little while, maybe you could post your partial patch in case someone else wants to work on it?  Might be a good project for someone on the mentoring list.

Unless someone sees a clever way to implement both with the same mechanism, parameterizing test cases should probably be a separate issue.  Doing it via subclassing is straightforward, which also argues for a separate issue, since an 'is this worth it' discussion should be done separately for that feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:03:26 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 20 Jul 2011 14:03:26 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311170606.02.0.777117833155.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

*If* we add this to unittest then we need to decide between test load time parameterised tests and test run time parameterisation. 

Load time is more backwards compatible / easier (all tests can be generated at load time and the number of tests can be known). Run time is more useful. (With load time parameterisation the danger is that test generation can fail so we need to have the test run not bomb out in this case.)

A hack for run time parameterisation is to have all tests represented by a single test but generate a single failure that represents all the failures. I think this would be an acceptable approach. It could still be done with a decorator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:03:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Jul 2011 14:03:55 +0000
Subject: [issue12524] change httplib docs POST example
In-Reply-To: <1310288732.05.0.896091983102.issue12524@psf.upfronthosting.co.za>
Message-ID: <1311170635.86.0.133878125817.issue12524@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the patch, Bharadwaj.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12524>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:06:02 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 20 Jul 2011 14:06:02 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311170762.43.0.11409994892.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

And yes, parameterising test cases is a different issue. bzr does this IIRC. This is easier in some ways, and can be done through load_tests, or any other test load time mechanism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:07:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 14:07:51 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311170871.7.0.44403123478.issue7897@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Michael, would your "single test" clearly indicate all the individual failures by name?  If not, then I would not find it useful.  I can already easily "parameterize" inside a single test using a loop, it's the detailed reporting piece that I want support for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:12:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 14:12:08 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311171128.63.0.558880861768.issue7897@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The reporting piece, and ideally being able to use the arguments to unittest to run a single one of the parameterized tests.  (I can get the reporting piece now using the locals() hack, but that doesn't support test selection).  Does test selection support required load time parameterization?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:17:02 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 20 Jul 2011 14:17:02 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311171422.13.0.300016360764.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Test selection would require load time parameterisation - although the current test selection mechanism is through importing which would probably *not* work without a specific fix. Same for run time parameterisation.

Well how *exactly* you generate the names is an open question, and once you've solved that problem it should be no harder to show them clearly in the failure message with a "single test report" than with multiple test reports.

The way to generate the names is to number each test *and* show the parameterised data as part of the name (which can lead to *huge* names if you're not careful - or just object reprs in names which isn't necessarily useful). I have a decorator example that does runtime parameterisation, concatenating failures to a single report but still keeping the generated name for each failure.

Another issue is whether or not parameterised tests share a TestCase instance or have separate ones. If you're doing load time generation it makes sense to have a separate test case instance, with setUp and tearDown run individually. This needs to be clearly documented as the parameter generation would run against an uninitialised (not setUp) testcase.

Obviously reporting multiple test failures separately (run time parameterisation) is a bit nicer, but runtime test generation doesn't play well with anything that works with test suites - where you expect all tests to be represented by a single test case instance in the suite. I'm not sure that's a solveable problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:19:56 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 20 Jul 2011 14:19:56 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311171596.95.0.402137434783.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Dammit, I've reversed my thinking in some of those messages. Load time parameterisation *does* give you separate test reporting. It is run time parameterisation that doesn't.

Depending on how you do it (i.e. if the decorator generates the tests and attaches them as TestCase methods) you can do it at import time. And then normal test selection works if you know the test name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:28:35 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 20 Jul 2011 14:28:35 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311172115.37.0.0608656408724.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

So if we do import time *or* test load time parameterisation then we can do separate failure reporting. We may still want to improve "test selection" for parameterised tests.

There are use cases for run time parameterisation (for example generating tests from a database that is only available during the test run was one use case someone has that can't be met by early parameterisation).

If we do run time parameterisation then I think we can only maintain compatibility with existing uses of test suites by having a single test case instance per parameterised test, and single combined failure report.

I would prefer *not* to add run time parameterisation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:36:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 14:36:41 +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: <1311172601.52.0.778171297919.issue8728@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If possible, the code example would use only Python, not httplib2 or Active State Python :)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8728>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:38:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 14:38:04 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1311172684.36.0.392497372718.issue12555@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22705/40ae82fafaed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:44:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 14:44:30 +0000
Subject: [issue7620] Vim syntax highlight
In-Reply-To: <1262445013.64.0.818540648921.issue7620@psf.upfronthosting.co.za>
Message-ID: <1311173070.59.0.285469833493.issue7620@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your willingness to contribute to Python and your work on a patch.  We?re currently debating whether we should update or remove the Misc/Vim files, on #9893, so if we reach an agreement that maintaining these files is too costly for little benefit, you will have worked in vain.  Sorry if that happens, and I hope you?ll find other bugs where your patches will be accepted.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7620>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:45:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jul 2011 14:45:37 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1311173137.77.0.303945667408.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Wed Jul 20 16:47:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 14:47:09 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1311173229.44.0.152591949386.issue12555@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The patch looks good.  I can?t comment on details of the C code, but I?ve seen the changed Python code and the tests and I like this.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Wed Jul 20 17:00:57 2011
From: report at bugs.python.org (Christoph Schindler)
Date: Wed, 20 Jul 2011 15:00:57 +0000
Subject: [issue12594] Docs for py3k still refer to "MacPython 2.5 folder"
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>


New submission from Christoph Schindler <hop at 30hopsmax.at>:

In http://docs.python.org/py3k/using/mac.html#getting-and-installing-macpython and http://docs.python.org/py3k/using/mac.html#distributing-python-applications-on-the-mac .

----------
assignee: docs at python
components: Documentation
messages: 140744
nosy: docs at python, hop
priority: normal
severity: normal
status: open
title: Docs for py3k still refer to "MacPython 2.5 folder"
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12594>
_______________________________________

From report at bugs.python.org  Wed Jul 20 17:11:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 15:11:52 +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: <1311174712.72.0.487859227279.issue11176@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I worked on this some time ago; the problem was the size of the
> documentation, i.e. it was difficult to stay consistent.
I think it?s okay to improve the docs one patch at a time, starting with the simple example referenced in the first message in this bug report, and gradually improving other sections.  Do you have a diff with your work, so that your efforts can serve as a base for someone else?

> Do I have time for this?  Yes, but I wouldn't get it done anytime
> soon, and the results could be anywhere from good to bad.
That?s why we do reviews :)  It?s okay if you don?t have time, I?m interested in working on this some time in the future.

----------
assignee: docs at python -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Wed Jul 20 17:16:31 2011
From: report at bugs.python.org (Tobias Pfaff)
Date: Wed, 20 Jul 2011 15:16:31 +0000
Subject: [issue12595] python.h redundant redeclarations
In-Reply-To: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>
Message-ID: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>


New submission from Tobias Pfaff <tobias.pfaff at inf.ethz.ch>:

Compiling 'Python.h' with g++ and -Wredundant-decls produces warnings

Testcase:

test.cpp:
#include <Python.h>
int main() { return 0; }

g++ test.cpp -I/usr/include/python3.2mu/ -Wredundant-decls
In file included from /usr/include/python3.2mu/Python.h:106,
                 from test.cpp:1:
/usr/include/python3.2mu/pyerrors.h:73: warning: redundant redeclaration of ?void Py_FatalError(const char*)? in same scope
/usr/include/python3.2mu/pydebug.h:29: warning: previous declaration of ?void Py_FatalError(const char*)?

----------
components: Build
messages: 140746
nosy: verticalduck
priority: normal
severity: normal
status: open
title: python.h redundant redeclarations
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12595>
_______________________________________

From report at bugs.python.org  Wed Jul 20 17:41:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jul 2011 15:41:45 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <E1QjYu7-0001Wt-Mw@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5f7b03dcd523 by R David Murray in branch 'default':
#665194: support roundtripping RFC2822 date stamps in the email.utils module
http://hg.python.org/cpython/rev/5f7b03dcd523

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665194>
_______________________________________

From report at bugs.python.org  Wed Jul 20 17:44:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 15:44:32 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1311176672.13.0.7029820575.issue12581@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Wed Jul 20 17:46:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 15:46:22 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1311176782.58.0.651476509839.issue665194@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fixed a bug (parsedate_to_datetime wasn't producing naive datetimes for -0000) and checked this in.

Note that I have added Alexander's 'localtime' function to email.utils in my feature branch/pypi release, to facilitate testing date headers.  If localtime gets added to datetime before 3.3 I'll remove it from email.utils.  The email package itself does not depend on having localtime, but it will be wanted by application programs that use email.

----------
dependencies:  -Add aware local time support to datetime module
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue665194>
_______________________________________

From report at bugs.python.org  Wed Jul 20 17:53:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 15:53:26 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1311177206.79.0.320388401417.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I temporarily retract my request for addition of build_distinfo.

Other build_spam/install_spam commands have clear responsibilities: build creates files, install moves them.  This is the classic make/make install division of work, where you may want to run build frequently when updating C code, and you may want to run install as root.

For the dist-info files, we?ve seen that the RECORD file cannot be generated at build time, only install time, so splitting a build_distinfo command out of install_distinfo does not make sense.

The develop command can continue to call install_distinfo in the build dir, writing a RECORD file containing only the path to the pth file.  (Let?s continue that discussion on the develop bug.)

For the test command, we could either require people to run develop, or run install_distinfo in the build dir.  I think the latter is nicer.  Who wants to make a patch for that?

For the resources API, which should work even in an unbuilt checkout or unarchived tarball, that?s another bug.

----------
resolution:  -> later
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Wed Jul 20 18:20:52 2011
From: report at bugs.python.org (=?utf-8?q?Philipp_M=C3=B6lders?=)
Date: Wed, 20 Jul 2011 16:20:52 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>


New submission from Philipp M?lders <philipp.moelders at googlemail.com>:

I think there is a problem within cPickle. I wanted to store a dictionary with only one entry with cPickle.dump() this works fine and can be loaded with cPickle.load(). But if you store the loaded data with cPickle.dump() again, the stored data differ from the first stored data. But the load works fine only the written data on disk differ. I've written a sample script, that shows the problem within code. 
This problem occurs only in the 2.7 version of Python and only with dictionaries with one entry.

----------
components: None
files: cPickletest.py
messages: 140750
nosy: Philipp.M?lders
priority: normal
severity: normal
status: open
title: cPickle - stored data differ for same dictionary
versions: Python 2.7
Added file: http://bugs.python.org/file22706/cPickletest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12596>
_______________________________________

From report at bugs.python.org  Wed Jul 20 18:22:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 20 Jul 2011 16:22:10 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311178930.11.0.70112463427.issue7897@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/issue7897>
_______________________________________

From report at bugs.python.org  Wed Jul 20 18:24:12 2011
From: report at bugs.python.org (=?utf-8?q?Philipp_M=C3=B6lders?=)
Date: Wed, 20 Jul 2011 16:24:12 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1311179052.86.0.378667390688.issue12596@psf.upfronthosting.co.za>


Changes by Philipp M?lders <philipp.moelders at googlemail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12596>
_______________________________________

From report at bugs.python.org  Wed Jul 20 18:25:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 16:25:52 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1311179152.06.0.665893503273.issue12596@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If the load produces the same result, why does it matter that what is on disk differs?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12596>
_______________________________________

From report at bugs.python.org  Wed Jul 20 18:34:28 2011
From: report at bugs.python.org (=?utf-8?q?Philipp_M=C3=B6lders?=)
Date: Wed, 20 Jul 2011 16:34:28 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1311179668.22.0.212556627918.issue12596@psf.upfronthosting.co.za>


Philipp M?lders <philipp.moelders at googlemail.com> added the comment:

The file on disk matters for a replication service, so if a file is touched but not changed it will not be replicated, but in this special case the data change even when the structures have not changed. So if this happens very often it could cause a lot of replication which is not needed because nothing changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12596>
_______________________________________

From report at bugs.python.org  Wed Jul 20 18:38:59 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPRltC5INCX0LDQs9C+0YDRltGP?=)
Date: Wed, 20 Jul 2011 16:38:59 +0000
Subject: [issue12597] List created by multiplication behaves different
In-Reply-To: <1311179939.37.0.721562945719.issue12597@psf.upfronthosting.co.za>
Message-ID: <1311179939.37.0.721562945719.issue12597@psf.upfronthosting.co.za>


New submission from ?????? ??????? <xintx.ua at gmail.com>:

Next code:

def ill(row):
  row[1]=1
list_manual=[[0,0,0],[0,0,0],[0,0,0]]
list_generated=[[0,0,0]]*3
ill(list_manual[1])
print(list_manual)
ill(list_generated[1])
print(list_generated)

Will output:

[[0, 0, 0], [0, 1, 0], [0, 0, 0]]
[[0, 1, 0], [0, 1, 0], [0, 1, 0]]

Is it a bug?

----------
messages: 140753
nosy: xintx-ua
priority: normal
severity: normal
status: open
title: List created by multiplication behaves different
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/issue12597>
_______________________________________

From report at bugs.python.org  Wed Jul 20 19:07:10 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 20 Jul 2011 17:07:10 +0000
Subject: [issue12597] List created by multiplication behaves different
In-Reply-To: <1311179939.37.0.721562945719.issue12597@psf.upfronthosting.co.za>
Message-ID: <1311181630.55.0.746547682604.issue12597@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi,
no it's not a bug :)

What you actually get with [[0]]*3 is a list of 3 references to the same list, [0]:

>>> a = [[0], [0], [0]]
>>> b = [[0]]*3
>>> for i in a: print(id(i))
... 
139807725184032
139807725300280
139807725300520
>>> for i in b: print(id(i))
... 
139807725324016
139807725324016
139807725324016

----------
nosy: +sandro.tosi
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12597>
_______________________________________

From report at bugs.python.org  Wed Jul 20 19:31:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 17:31:59 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1311183119.01.0.947862978308.issue2259@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, if the test doesn't fail before applying the remainder of the patch, then it doesn't test the bits that haven't been applied yet.

I don't know enough about aifc to construct a test that fails or to understand the remainder of the fix well enough to feel comfortable committing it *without* a test that fails first.  So I'm hoping someone else will be able to figure it out :)  Thanks for trying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Wed Jul 20 19:50:58 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPRltC5INCX0LDQs9C+0YDRltGP?=)
Date: Wed, 20 Jul 2011 17:50:58 +0000
Subject: [issue12597] List created by multiplication behaves different
In-Reply-To: <1311179939.37.0.721562945719.issue12597@psf.upfronthosting.co.za>
Message-ID: <1311184258.88.0.999529806782.issue12597@psf.upfronthosting.co.za>


?????? ??????? <xintx.ua at gmail.com> added the comment:

So the workaround is

for i in range(len(list_generated)):
  list_generated[i]=list(tuple(list_generated[i]))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12597>
_______________________________________

From report at bugs.python.org  Wed Jul 20 19:53:56 2011
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 20 Jul 2011 17:53:56 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1311005926.87.0.271612716216.issue8668@psf.upfronthosting.co.za>
Message-ID: <4E27176C.5040307@dirtcircle.com>


Carl Meyer <carl at dirtcircle.com> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> [Carl]
>> there's an implicit assumption that a .pth file is the most likely
>> strategy.
> If you have other ideas, please share them.

No, I think that's the most promising strategy. The "implicit
assumption" comment was not criticism, just explanation for Michael.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4nF2wACgkQ1j/fhc23WEDvlwCeK3Y+MJGyb3uoEzYzJWaSCrTy
WewAoI7UdW+nqP2SEtquvQXCndXX57VO
=UFOY
-----END PGP SIGNATURE-----

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Wed Jul 20 19:58:29 2011
From: report at bugs.python.org (Landry Breuil)
Date: Wed, 20 Jul 2011 17:58:29 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311184709.76.0.163940030906.issue12589@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

$python3.2                                            
Python 3.2.1 (default, Jul 18 2011, 10:56:33) 
[GCC 4.2.1 20070719 ] on openbsd4
>>> int(float('inf'))
0
$sysctl hw                                            
hw.machine=macppc

----------
nosy: +landry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Wed Jul 20 19:59:57 2011
From: report at bugs.python.org (Landry Breuil)
Date: Wed, 20 Jul 2011 17:59:57 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311184797.93.0.290271909983.issue12588@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

(gdb) r
Starting program: /usr/obj/ports/Python-3.2.1/Python-3.2.1/Modules/_testembed 
--- Pass 0 ---
interp 0x90ae7300, thread state 0x87b48a00: id(modules) = 2363177552
interp 0x90ae7a40, thread state 0x87b48a80: id(modules) = 2243881408
interp 0x90ae7cc0, thread state 0x87b48100: id(modules) = 2216467744
interp 0x90ae7ec0, thread state 0x87b48180: id(modules) = 2221503376
interp 0x90ae7300, thread state 0x87b48a00: id(modules) = 2363177552
--- Pass 1 ---
interp 0x0, thread state 0x87b48a00: 
Program received signal SIGSEGV, Segmentation fault.
0x8cb70094 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
(gdb) bt
#0  0x8cb70094 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
#1  0x8cb70070 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
#2  0x8cb70070 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
#3  0x8cb70070 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
#4  0x8cb70070 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
#5  0x8cb70070 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
#6  0x8cb70070 in PyImport_GetModuleDict () from /usr/local/lib/libpython3.2m.so.1.0
Previous frame inner to this frame (corrupt stack?)

----------
nosy: +landry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Wed Jul 20 20:15:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jul 2011 18:15:23 +0000
Subject: [issue12597] List created by multiplication behaves different
In-Reply-To: <1311179939.37.0.721562945719.issue12597@psf.upfronthosting.co.za>
Message-ID: <1311185723.05.0.601193293722.issue12597@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure what your example is trying to achieve, but the list(tuple(...)) looks redundant.

Your initial example could be written:

  b = [[0] for i in range(3)]

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12597>
_______________________________________

From report at bugs.python.org  Wed Jul 20 20:53:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Jul 2011 18:53:00 +0000
Subject: [issue12594] Docs for py3k still refer to "MacPython 2.5 folder"
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1311187980.89.0.299078055062.issue12594@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report.  The whole "Using Python on a Macintosh" section is very out-of-date and needs a major update.

----------
assignee: docs at python -> ned.deily
nosy: +ned.deily
stage:  -> needs patch
versions: +Python 2.7, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12594>
_______________________________________

From report at bugs.python.org  Wed Jul 20 22:58:46 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 20 Jul 2011 20:58:46 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311195526.84.0.505165795116.issue12588@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Hi Landry , what is result if you move _testembed to upper directory and run it with environment so that shared python library from upper to be loaded (LD_LIBRARY_PATH=.... )?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Wed Jul 20 23:03:44 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Jul 2011 21:03:44 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311195824.67.0.40436673002.issue12576@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I think this is also a regression in Python 2.7, as reported here:

https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/813295

----------
nosy: +barry
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Wed Jul 20 23:10:46 2011
From: report at bugs.python.org (Landry Breuil)
Date: Wed, 20 Jul 2011 21:10:46 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311196246.18.0.224744792897.issue12588@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

You get the same issue :


[23:08] mikey:/usr/obj/ports/Python-3.2.1/Python-3.2.1/ $cp Modules/_testembed .                     
[23:08] mikey:/usr/obj/ports/Python-3.2.1/Python-3.2.1/ $LD_LIBRARY_PATH=. gdb _testembed
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-openbsd4.9"...(no debugging symbols found)

(gdb) r
Starting program: /usr/obj/ports/Python-3.2.1/Python-3.2.1/_testembed 
--- Pass 0 ---
interp 0x90d4a440, thread state 0x81855380: id(modules) = 2201418320
interp 0x90d4a580, thread state 0x81855600: id(modules) = 2259298752
interp 0x90d4a880, thread state 0x81855480: id(modules) = 2246904544
interp 0x90d4acc0, thread state 0x81855500: id(modules) = 2328741616
interp 0x90d4a440, thread state 0x81855380: id(modules) = 2201418320
--- Pass 1 ---
interp 0x0, thread state 0x81855380: 
Program received signal SIGSEGV, Segmentation fault.
0x8eb95094 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
(gdb) bt
#0  0x8eb95094 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
#1  0x8eb95070 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
#2  0x8eb95070 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
#3  0x8eb95070 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
#4  0x8eb95070 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
#5  0x8eb95070 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
#6  0x8eb95070 in PyImport_GetModuleDict () from ./libpython3.2m.so.1.0
Previous frame inner to this frame (corrupt stack?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Thu Jul 21 00:26:25 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Jul 2011 22:26:25 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311200785.89.0.641571794334.issue12583@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

For the ImportWarning docs, there could stand to be more; patches welcome. =)

As for ImportError being postmortem on an error, that is not always true as plenty of people use the trick, e.g.:

try: import json
except ImportError: import simplejson as json

As for detecting circular imports, flagging it somehow might work, but directly analyzing the stack won't do since that is extremely costly on some VMs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:07:48 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 20 Jul 2011 23:07:48 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311203268.54.0.54549560626.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Load time parameterisation seems more of a worthwhile addition to me, too. As David noted, runtime parameterisation is pretty easy to do by looping and consolidating failures into the one error message via self.fail().

For test naming, trying to get too clever seems fraught with peril. I'd be happy with something like:
1. Parameterised tests are just numbered sequentially by default
2. The repr of the test parameters is included when displaying detailed error messages
3. A hook is provided to allow customisation of the naming scheme and test parameters. This hook receives an iterable of test parameters and is expected to create a new iterable producing 2-tuples of test names and parameters.

The default behaviour of the parameterised test generator could then be something like:

def parameterised_test_info(name, cases):
    for idx, case in enumerate(cases, start=1):
        yield ("{}_{}".format(name, idx), case)

The new machinery (however provided) would then take care of checking the names are unique, adding those methods to the test case, and storing the parameters somewhere convenient (likely as attributes of the created methods) for use when running the test and when displaying error messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:12:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Jul 2011 23:12:50 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <E1Qjfwe-0008EB-SZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cb44fef5ea1d by Antoine Pitrou in branch 'default':
Issue #12551: Provide a get_channel_binding() method on SSL sockets so as
http://hg.python.org/cpython/rev/cb44fef5ea1d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:13:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Jul 2011 23:13:48 +0000
Subject: [issue12551] Provide data for TLS channel binding
In-Reply-To: <1310556805.74.0.156740266858.issue12551@psf.upfronthosting.co.za>
Message-ID: <1311203628.05.0.223963916049.issue12551@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch is now committed. Thanks for your contribution!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12551>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:24:44 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 20 Jul 2011 23:24:44 +0000
Subject: [issue12598] Move sys variable initialization from import.c to
	sysmodule.c
In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za>
Message-ID: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Several import-related sys variables are set in _PyImportHooks_Init (in Python/import.c), which is called in Python/pythonrun.c.  I have included a patch that moves that initialization from _PyImportHooks_Init to a new _SysImportState_Init function in Python/sysmodule.c, which is then called from _PyImportHooks_Init.

This may seem like an unnecessary change, but sysmodule.c is the obvious place to find the initialization of sys variables.  Other than in pythonrun.c, import.c is the only place that sys variables are set outside of sysmodule.c.

Finally, several import related projects[1] are coming up that will impact import.c and _PyImportHooks_Init specifically.  This change helps clean up import.c a little in preparation for those projects, and isolates out of import.c at least one thing that should be kept safe during any import.c refactoring.

[1] see issue #2377, PEP 402, and the GSOC import engine project.

----------
files: sys_import_state.diff
keywords: patch
messages: 140769
nosy: ericsnow
priority: normal
severity: normal
status: open
title: Move sys variable initialization from import.c to sysmodule.c
Added file: http://bugs.python.org/file22707/sys_import_state.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12598>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:29:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 20 Jul 2011 23:29:47 +0000
Subject: [issue12598] Move sys variable initialization from import.c to
	sysmodule.c
In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za>
Message-ID: <1311204587.61.0.681404919033.issue12598@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12598>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:33:28 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 20 Jul 2011 23:33:28 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311204808.84.0.639311849396.issue7897@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:34:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 20 Jul 2011 23:34:26 +0000
Subject: [issue12599] Use 'is not None' where appropriate in importlib
In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za>
Message-ID: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Problems noted by PJE on import-sig:
====================================
For example, PathFinder's find_module treats an empty path the same as sys.path, and will also fail if for some reason the bool() of a PEP 302 finder or loader object is False.  Also, module_for_loader() will create a new module object, if you have a False module subclass in sys.modules.

...

These distinctions could be more problematic than they appear, as it's possible to inadvertently make your loader or your module subclass capable of being False (for example, if you subclassed a sequence type or implemented a __len__), and this could lead to some very subtle bugs, albeit very rare ones as well.  ;-)
===================================

The import test cases should include some examples of such pathological objects, with importlib then updated appropriately.

----------
assignee: brett.cannon
messages: 140770
nosy: brett.cannon, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Use 'is not None' where appropriate in importlib
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12599>
_______________________________________

From report at bugs.python.org  Thu Jul 21 01:57:51 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 20 Jul 2011 23:57:51 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311206271.26.0.302297547372.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

That all sounds good to me Nick. Some notes / questions.

How should parameterised tests be marked? I'm happy with a unittest.parameterized decorator (it would do no work other than mark the test method, with the parameterisation being done in the TestLoader).

What could the "name customisation hook" look like? A module level hook (yuck) / a class method hook on the TestCase that must handle every parameterised test on that TestCase / a decorator for the parameterised test method?

If we do it at load time should we require parameterised methods to be class methods? The alternative is to instantiate the test case when loading and collecting the tests. Class methods won't play well with the other unittest decorators as you can't attach attributes to classmethods. (So I guess instance methods it is!)

If collecting tests fails part way through we should generate a failing test that reports the exception. Should the tests collected "so far" be kept?

Should skip / expectedFail decorators still work with them? If so they'll need custom support I expect.

If we're generating test names and then attaching these tests to TestCase instances (so that normal test case execution will run them), should we check for name clashes? What should we do if there is a name clash? (The generated name would shadow an existing name.) We could prevent that by using a non-identifier name - e.g. "${}_{}".format(name, idx)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 02:01:25 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 Jul 2011 00:01:25 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311206485.56.0.665907577489.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Oh, and if we're not going to get clever with naming, how is the TestResult going to include the parameter repr in the failure report? That information will have to be stored on the TestCase. 

I would prefer this feature not to touch the TestResult - so any failure message cleverness should be done in the TestCase. It will be harder to maintain if this feature is spread out all the way through unittest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 02:01:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Jul 2011 00:01:52 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311206512.28.0.398764748065.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This nasty bug really can cause severe problems. If a zombie process ran a tkinter (tk) window, then attempting to logout/restart/shutdown eventually brings up a window I have never seen before: End Process -- EmbeddedMenuWindow. The message window shows a countdown timer that implies that it will shutdown the process automatically when the timer reaches 0. But it does not because the process does not respond. It will sit there indefinitely. One has to click a shutdown button to get rid of it.  Then a few seconds later, another window for the next zombie appears. And so on. It there are 50 zombies, then one would have to repeat 50 times. Not acceptible to me.

Since IDLE is my Python workspace and since I plan to soon start running lots of tkinter tests and experiments soon, I am reverting to 3.2.0 until there is a fixed Windows binary.

Adding the two listed Windows experts.

----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Thu Jul 21 02:13:25 2011
From: report at bugs.python.org (Ori Livneh)
Date: Thu, 21 Jul 2011 00:13:25 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1311207205.53.0.471277999863.issue11197@psf.upfronthosting.co.za>


Ori Livneh <ori.livneh at gmail.com> added the comment:

Yes, I seem to have gotten confused about this. Sorry for the confusion, and thanks for clearing it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Thu Jul 21 04:08:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Jul 2011 02:08:02 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311214082.03.0.390750744795.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Restart is not required to create a zombie. Just start IDLE and quit, and the second, user process does not disappear.

Reverting completely does not seem possible. I first just ran the 3.2 installer and it did not complain, that I noticed, about replacing a newer version, but apparently only replaced .exe and .dll and a few other files but not Lib/*.py. Idle or command prompt window said it was still 3.2.1 and the bug remained.

So I uninstalled, deleted everything left except my .py files in site-packages and another subdirectory, and reinstalled 3.2. Now everything seems to predate 2/22/2011. BUT IDLE and command prompt window *still* report "Python 3.2.1 (default, Jul 10 2011, 21:51:15) [MSC v.1500 32 bit (Intel)] on win32". This is sys.version. Something somewhere (registry?) seems to not be deleted by uninstall.  And the bug remains. Could a registry entry possibly affect this?

My system is 7 years old with updated win xp 32 bit.

I then checked the never updated 64 bit Py 3.2 on an 18 month old 64 bit Win 7 laptop and detached user processes *do* disappear as I remember on this machine. It did, however, take 8 sec over restart and 12 after closing, which is longer than I remember for my older and definitely slower machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Thu Jul 21 04:23:29 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 02:23:29 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311215009.68.0.692037192417.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Here's a sketch for a possible decorator factory:

def parameters(params, *, builder=_default_param_builder):
    def make_parameterized_test(f):
        return ParameterizedTest(f, params, builder)
    return make_parameterized_test

(default builder would be the one I sketched earlier)

Example usage:

ExampleParams = namedtuple('ExampleParams', 'x y')
all_cases = [ExampleParams(x, y) for x in range(3) for y in range(3)]

def x_y_naming(name, cases):
    for idx, case in enumerate(cases, start=1):
        x, y = case
        yield ("{}_{}_{}_{}".format(name, idx, x, y), case)

class ExampleTestCase(TestCase):
  @parameters(all_cases)
  def test_example_auto_naming(self, x, y):
      self.assertNotEqual(x, y) # fails sometimes :)

  @parameters(all_cases, builder=x_y_naming)
  def test_example_custom_naming(self, x, y):
      self.assertNotEqual(x, y) # fails sometimes :)

Once defined, you're far better equipped than I am to decide how TestLoader and TestCase can best cooperate to generate appropriate test operations and error messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 04:30:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 21 Jul 2011 02:30:45 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311215445.33.0.563551406611.issue12540@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/issue12540>
_______________________________________

From report at bugs.python.org  Thu Jul 21 04:34:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jul 2011 02:34:25 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311215665.47.0.97507808746.issue7897@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Personally I would be happy if I could pass in a dictionary that maps names to argument tuples, or an iterator yielding (name, (argtuple)) pairs, and just have the failure report the name.  That is, make me responsible for generating meaningful names, don't autogenerate them.  Then someone could provide a name autogenerate helper on top of that base interface. 

Checking for name clashes would be nice, but it would be nice to have that for non-parameterized test cases, too (I've been bitten by that a number of time ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 05:46:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 03:46:13 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311219973.17.0.629464560055.issue7897@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/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 06:20:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 04:20:56 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1311222056.11.0.902549959249.issue12266@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +belopolsky, eric.araujo, ezio.melotti, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Thu Jul 21 06:21:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 04:21:26 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1311222086.58.0.0166383380022.issue12204@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a patch.
I don't think it's necessary to update the docstring.

----------
assignee: docs at python -> ezio.melotti
keywords: +patch
stage:  -> commit review
Added file: http://bugs.python.org/file22708/issue12204.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Thu Jul 21 06:54:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 04:54:56 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1311224096.44.0.973299842307.issue12204@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch that factors out the definition of cased characters adding it to a footnote.

----------
Added file: http://bugs.python.org/file22709/issue12204-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Thu Jul 21 06:59:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 04:59:52 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1311224392.62.0.998821852335.issue12266@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Indeed this seems a different issue, and might be worth fixing it.
Given this definition:
  str.capitalize()?
      Return a copy of the string with its first character capitalized and the rest lowercased.
we might implement capitalize like:
>>> def mycapitalize(s):
...     return s[0].upper() + s[1:].lower()
... 
>>> 'fOoBaR'.capitalize()
'Foobar'
>>> mycapitalize('fOoBaR')
'Foobar'

And this would yield the correct result:
>>> s = u'\u1ff3\u1ff3\u1ffc\u1ffc'
>>> print s
????
>>> print s.capitalize()
????
>>> print mycapitalize(s)
????
>>> s.capitalize().istitle()
False
>>> mycapitalize(s).istitle()
True

This doesn't happen because the actual implementation of str.capitalize checks if a char is uppercase (and not if it's titlecase too) before converting it to lowercase.  This can be fixed doing:
diff -r cb44fef5ea1d Objects/unicodeobject.c
--- a/Objects/unicodeobject.c   Thu Jul 21 01:11:30 2011 +0200
+++ b/Objects/unicodeobject.c   Thu Jul 21 07:57:21 2011 +0300
@@ -6739,7 +6739,7 @@
     }
     s++;
     while (--len > 0) {
-        if (Py_UNICODE_ISUPPER(*s)) {
+        if (Py_UNICODE_ISUPPER(*s) || Py_UNICODE_ISTITLE(*s)) {
             *s = Py_UNICODE_TOLOWER(*s);
             status = 1;
         }

----------
assignee:  -> ezio.melotti
status: closed -> open
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:08:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:08:31 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1311224911.57.0.650639754637.issue11975@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

To distinguish the 'int' in functions.rst from the one in stdtypes.rst (if it works...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:11:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:11:00 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1311225060.15.0.724609414798.issue12301@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12301>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:14:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:14:12 +0000
Subject: [issue3665] Support \u and \U escapes in regexes
In-Reply-To: <1219610032.28.0.862215531927.issue3665@psf.upfronthosting.co.za>
Message-ID: <1311225252.95.0.934937601184.issue3665@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3665>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:22:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:22:24 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1311225744.01.0.0402121579674.issue11113@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Having them in different mappings would be good, but I expect that for most real world application a single mappings that includes them all is the way to go.  If I'm parsing a supposedly HTML page that contains an &apos; I'd rather have it converted even if it's not an HTML entity.
If the set of entities supported by HTML5 is a superset of the HTML4 and XHTML ones, than we might just use that (I haven't checked though).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11113>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:27:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:27:20 +0000
Subject: [issue8887] "pydoc str" works but not "pydoc str.translate"
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1311226040.27.0.260936564668.issue8887@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: patch review -> commit review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:28:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:28:54 +0000
Subject: [issue12298] Sphinx glitch in library/functions
In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za>
Message-ID: <1311226134.65.0.65070683052.issue12298@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12298>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:39:29 2011
From: report at bugs.python.org (Austin Bingham)
Date: Thu, 21 Jul 2011 05:39:29 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>


New submission from Austin Bingham <austin.bingham at gmail.com>:

In the discussion about adding support for parameterized tests (issue 7897), it seemed clear that parameterizing individual tests was a different issue from parameterizing TestCases. This, then, is a request to support parameterization of TestCases.

The fundamental idea is that one should be able to define a TestCase - fixtures, individual tests, etc. - and then be able to reuse that TestCase with different sets of parameters. This should all mesh cleanly with the rest of the unittest system, though it's not entirely clear what that entails.

As a motivation, consider a TestCase that tests the public API for a database abstraction system. The abstraction may work against any of a number of backends, but the public API remains the same for each. A parameterized TestCase would let you write one test for the public API and then run it for each of the backends.

----------
components: Tests
messages: 140784
nosy: abingham
priority: normal
severity: normal
status: open
title: Support parameterized TestCases in unittest
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:40:27 2011
From: report at bugs.python.org (Austin Bingham)
Date: Thu, 21 Jul 2011 05:40:27 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1311170602.01.0.108817720696.issue7897@psf.upfronthosting.co.za>
Message-ID: <CAEZidR11=Jfuf0QhUydittsgX+2wqaTP1kYZGHS5dJCgGtUBxg@mail.gmail.com>


Austin Bingham <austin.bingham at gmail.com> added the comment:

OK, I created issue 12600 for dealing with parameterized TestCases as
opposed to individual tests.

On Wed, Jul 20, 2011 at 4:03 PM, R. David Murray <report at bugs.python.org> wrote:
> Unless someone sees a clever way to implement both with the same mechanism, parameterizing test cases should probably be a separate issue. ?Doing it via subclassing is straightforward, which also argues for a separate issue, since an 'is this worth it' discussion should be done separately for that feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:41:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:41:09 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311226869.59.0.913250684846.issue12600@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +Yaroslav.Halchenko, brian.curtin, eric.araujo, ericsnow, exarkun, ezio.melotti, fperez, michael.foord, nchauvat, ncoghlan, pitrou, r.david.murray
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:47:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:47:15 +0000
Subject: [issue12401] unset PYTHON* environment variables when running tests
In-Reply-To: <1308952676.91.0.708236346954.issue12401@psf.upfronthosting.co.za>
Message-ID: <1311227235.61.0.495862307177.issue12401@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12401>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:47:31 2011
From: report at bugs.python.org (Aneesh)
Date: Thu, 21 Jul 2011 05:47:31 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311227251.33.0.920964592814.issue12540@psf.upfronthosting.co.za>


Aneesh <aneeshbaby at gmail.com> added the comment:

We are also noticed same issue and reverted to Python 3.1. Whenever we run a script, two new pythonw.exe process is started and it is really irritating to see all in Windows Task Manager. 

Last day I killed around 14 Pythonw.exe to clean up everything.

----------
nosy: +Aneesh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Thu Jul 21 07:58:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 05:58:37 +0000
Subject: [issue11363] Curses - add missing functions to doc
In-Reply-To: <1299005402.55.0.443028099437.issue11363@psf.upfronthosting.co.za>
Message-ID: <1311227917.56.0.460914870806.issue11363@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW the typo has been fixed in 13c9b93e97ad.
If the example is failing another issue should be created.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11363>
_______________________________________

From report at bugs.python.org  Thu Jul 21 08:07:50 2011
From: report at bugs.python.org (lekma)
Date: Thu, 21 Jul 2011 06:07:50 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1311228470.15.0.108082032729.issue10271@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

Thank you very much for your help

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Thu Jul 21 08:38:53 2011
From: report at bugs.python.org (Mark Hammond)
Date: Thu, 21 Jul 2011 06:38:53 +0000
Subject: [issue11629] Reference implementation for PEP 397
In-Reply-To: <1300777913.25.0.357945805094.issue11629@psf.upfronthosting.co.za>
Message-ID: <1311230333.74.0.780061516052.issue11629@psf.upfronthosting.co.za>


Mark Hammond <skippy.hammond at gmail.com> added the comment:

The most recent version of PEP397 has removed all mentioned of this reference implementation - the C implementation at https://bitbucket.org/vinay.sajip/pylauncher/ is now the reference.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11629>
_______________________________________

From report at bugs.python.org  Thu Jul 21 08:39:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jul 2011 06:39:58 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <E1QjmvN-0005WW-Gs@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 79d2682c4fc5 by Ezio Melotti in branch '3.2':
#11435: link to the correct branch.
http://hg.python.org/cpython/rev/79d2682c4fc5

New changeset 3028b5ab92c0 by Ezio Melotti in branch 'default':
#11435: dummy merge with 3.2.
http://hg.python.org/cpython/rev/3028b5ab92c0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Thu Jul 21 08:42:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 06:42:07 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1311230527.47.0.74314057108.issue11435@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I fixed the URL in 3.2.

> The 2.7 docs link to the Subversion repo.  Can I update them?

2.7 doesn't have the source directive, do you want to replace all the svn links manually?
If so, either reopen this issue or create a new one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Thu Jul 21 08:46:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 06:46:43 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1311230803.12.0.110905104149.issue12568@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/issue12568>
_______________________________________

From report at bugs.python.org  Thu Jul 21 09:37:02 2011
From: report at bugs.python.org (rgpitts)
Date: Thu, 21 Jul 2011 07:37:02 +0000
Subject: [issue6820] Redefinition of HAVE_STRFTIME can cause compiler errors.
In-Reply-To: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>
Message-ID: <1311233822.6.0.568883002795.issue6820@psf.upfronthosting.co.za>


rgpitts <richard.pitts at cdl.co.uk> added the comment:

As Python 2.6 is now security only and 2.7 is last major release I've patched this against Python 3.2 because pyconfig.h hadn't changed much since 2.6.

I've done as Amaury suggested and changed the HAVE_XXX symbols to define 1 like autoconf. 'make patchcheck' has fixed some general formatting issues included in the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file22710/issue-6820.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6820>
_______________________________________

From report at bugs.python.org  Thu Jul 21 10:10:25 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 21 Jul 2011 08:10:25 +0000
Subject: [issue12601] Spelling error in the comments in the webbrowser module.
In-Reply-To: <1311235825.37.0.75314458473.issue12601@psf.upfronthosting.co.za>
Message-ID: <1311235825.37.0.75314458473.issue12601@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

At line 235 there is a comment which contains "secons" which should be changed to seconds.

----------
components: Library (Lib)
messages: 140793
nosy: maniram.maniram
priority: normal
severity: normal
status: open
title: Spelling error in the comments in the webbrowser module.
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12601>
_______________________________________

From report at bugs.python.org  Thu Jul 21 10:18:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jul 2011 08:18:46 +0000
Subject: [issue12601] Spelling error in the comments in the webbrowser module.
In-Reply-To: <1311235825.37.0.75314458473.issue12601@psf.upfronthosting.co.za>
Message-ID: <E1QjoSz-0004Zs-2F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3bc80b6f7cd8 by Ezio Melotti in branch '3.2':
#12601: fix typo.
http://hg.python.org/cpython/rev/3bc80b6f7cd8

New changeset d26c7b18fc9d by Ezio Melotti in branch 'default':
#12601: merge with 3.2.
http://hg.python.org/cpython/rev/d26c7b18fc9d

New changeset 0127716200c7 by Ezio Melotti in branch '2.7':
#12601: fix typo.
http://hg.python.org/cpython/rev/0127716200c7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12601>
_______________________________________

From report at bugs.python.org  Thu Jul 21 10:19:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 08:19:34 +0000
Subject: [issue12601] Spelling error in the comments in the webbrowser module.
In-Reply-To: <1311235825.37.0.75314458473.issue12601@psf.upfronthosting.co.za>
Message-ID: <1311236374.5.0.844757749457.issue12601@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12601>
_______________________________________

From report at bugs.python.org  Thu Jul 21 10:31:41 2011
From: report at bugs.python.org (Tal Einat)
Date: Thu, 21 Jul 2011 08:31:41 +0000
Subject: [issue12590] First line and cursor not visible when opening files
In-Reply-To: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>
Message-ID: <1311237101.8.0.598668037227.issue12590@psf.upfronthosting.co.za>


Changes by Tal Einat <taleinat at gmail.com>:


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12590>
_______________________________________

From report at bugs.python.org  Thu Jul 21 10:34:22 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Jul 2011 08:34:22 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1311224392.62.0.998821852335.issue12266@psf.upfronthosting.co.za>
Message-ID: <4E27E487.3010802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think it would be better to use this code:

    if (!Py_UNICODE_ISUPPER(*s)) {
        *s = Py_UNICODE_TOUPPER(*s);
        status = 1;
    }
    s++;
    while (--len > 0) {
        if (Py_UNICODE_ISLOWER(*s)) {
            *s = Py_UNICODE_TOLOWER(*s);
            status = 1;
        }
        s++;
    }

Since this actually implements what the doc-string says.

Note that title case is not the same as upper case. Title case is
a special case that get's applied when using a string as a title
of a text and may well include characters that are lower case
but which are only used in titles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Thu Jul 21 10:38:28 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 21 Jul 2011 08:38:28 +0000
Subject: [issue12583] More detailed ImportError messages
In-Reply-To: <1311021933.2.0.965547827718.issue12583@psf.upfronthosting.co.za>
Message-ID: <1311237508.97.0.855326637645.issue12583@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Thanks for explaining, I guess it's too complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12583>
_______________________________________

From report at bugs.python.org  Thu Jul 21 10:52:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 08:52:55 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1311238375.93.0.206051053538.issue12266@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you mean  "if (!Py_UNICODE_ISLOWER(*s)) {"  (with the '!')?

This sounds fine to me, but with this approach all the uncased characters will go through a Py_UNICODE_TO* macro, whereas with the current code only the cased ones are converted.  I'm not sure this matters too much though.

OTOH if the non-lowercase cased chars are always either upper or titlecased, checking for both should be equivalent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Thu Jul 21 11:02:34 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Jul 2011 09:02:34 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1311238375.93.0.206051053538.issue12266@psf.upfronthosting.co.za>
Message-ID: <4E27EB23.9050700@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:
> 
> Do you mean  "if (!Py_UNICODE_ISLOWER(*s)) {"  (with the '!')?

Sorry, here's the correct version:

    if (!Py_UNICODE_ISUPPER(*s)) {
        *s = Py_UNICODE_TOUPPER(*s);
        status = 1;
    }
    s++;
    while (--len > 0) {
        if (!Py_UNICODE_ISLOWER(*s)) {
            *s = Py_UNICODE_TOLOWER(*s);
            status = 1;
        }
        s++;
    }

> This sounds fine to me, but with this approach all the uncased characters will go through a Py_UNICODE_TO* macro, whereas with the current code only the cased ones are converted.  I'm not sure this matters too much though.
> 
> OTOH if the non-lowercase cased chars are always either upper or titlecased, checking for both should be equivalent.

AFAIK, there are characters that don't have a case mapping at all.
It may also be the case, that a non-cased character still has a
lower/upper case mapping, e.g. for typographical reasons.

Someone would have to check this against the current Unicode database.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Thu Jul 21 11:02:46 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 21 Jul 2011 09:02:46 +0000
Subject: [issue12601] Spelling error in the comments in the webbrowser module.
In-Reply-To: <1311235825.37.0.75314458473.issue12601@psf.upfronthosting.co.za>
Message-ID: <1311238966.56.0.421985904398.issue12601@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

Thanks for the fast response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12601>
_______________________________________

From report at bugs.python.org  Thu Jul 21 11:09:09 2011
From: report at bugs.python.org (maniram maniram)
Date: Thu, 21 Jul 2011 09:09:09 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1311239349.72.0.0452039035056.issue12326@psf.upfronthosting.co.za>


maniram maniram <maniandram01 at gmail.com> added the comment:

It seems currently that in python 3.2 sys.platform is linux2 even though it is running linux 3

----------
nosy: +maniram.maniram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Jul 21 11:10:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jul 2011 09:10:53 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1311239453.6.0.762657652219.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It seems currently that in python 3.2 sys.platform is linux2
> even though it is running linux 3

It's maybe because you ran ./configure with Linux 2.x.y (see msg138254). Try make distclean && ./configure --with-debug && make.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Jul 21 11:33:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 09:33:42 +0000
Subject: [issue11669] Clarify Lang Ref "Compound statements" footnote
In-Reply-To: <1301042574.67.0.975748752077.issue11669@psf.upfronthosting.co.za>
Message-ID: <1311240822.66.0.765384833439.issue11669@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11669>
_______________________________________

From report at bugs.python.org  Thu Jul 21 11:45:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jul 2011 09:45:12 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311241512.35.0.723137813949.issue12589@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Thu Jul 21 12:05:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jul 2011 10:05:52 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311242752.91.0.518080111788.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Is HAVE_DECL_ISINF defined in pyconfig.h? PyLong_FromDouble() uses Py_IS_INFINITY(x):
--------------------------------------
/* Py_IS_INFINITY(X)
 * Return 1 if float or double arg is an infinity, else 0.
 * Caution:
 *    X is evaluated more than once.
 *    This implementation may set the underflow flag if |X| is very small;
 *    it really can't be implemented correctly (& easily) before C99.
 *    Override in pyconfig.h if you have a better spelling on your platform.
 *  Py_FORCE_DOUBLE is used to avoid getting false negatives from a
 *    non-infinite value v sitting in an 80-bit x87 register such that
 *    v becomes infinite when spilled from the register to 64-bit memory.
 * Note: PC/pyconfig.h defines Py_IS_INFINITY as _isinf
 */
#ifndef Py_IS_INFINITY
#  if defined HAVE_DECL_ISINF && HAVE_DECL_ISINF == 1
#    define Py_IS_INFINITY(X) isinf(X)
#  else
#    define Py_IS_INFINITY(X) ((X) &&                                   \
                               (Py_FORCE_DOUBLE(X)*0.5 == Py_FORCE_DOUBLE(X)))
#  endif
#endif
--------------------------------------

main() in Modules/python.c starts with:
--------------------------------------
    /* 754 requires that FP exceptions run in "no stop" mode by default,
     * and until C vendors implement C99's ways to control FP exceptions,
     * Python requires non-stop mode.  Alas, some platforms enable FP
     * exceptions by default.  Here we disable them.
     */
#ifdef __FreeBSD__
    fp_except_t m;

    m = fpgetmask();
    fpsetmask(m & ~FP_X_OFL);
#endif
--------------------------------------

You may try to enable this code on OpenBSD, replace "#ifdef __FreeBSD__" by "#if 1".

Can you also please try the following code?

$ python
>>> import struct
>>> struct.pack("f", float("inf"))
b'\x00\x00\x80\x7f'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Thu Jul 21 12:21:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jul 2011 10:21:51 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311243711.9.0.125251514692.issue12576@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Thu Jul 21 12:37:00 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 Jul 2011 10:37:00 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311244620.16.0.723206977387.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, pyflakes will tell you about name clashes within a TestCase (unless you're shadowing a test on a base class which I guess is rarely the case)...

When we generate the tests we could add the parameter reprs to the docstring. A decorator factor that takes arguments and an optional name builder seem like a reasonable api to me.

Actually, name clashes *aren't* a problem - as we're generating TestCase instances these generated tests won't shadow existing tests (you'll just have two tests with the same name - does this mean id() may not be unique - worth checking).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 12:42:50 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 21 Jul 2011 10:42:50 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1311244970.09.0.487600106614.issue12556@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> I don't like the idea of adding an argument which doesn't have a
> counterpart in the POSIX version (especially to address such corner
> cases).

Indeed, it seems rather messy for a corner case that may well not exist.

If there are definite cases where this usage is needed, a solution may then have to be considered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:02:52 2011
From: report at bugs.python.org (Sergei Lebedev)
Date: Thu, 21 Jul 2011 11:02:52 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1311246172.63.0.917851479965.issue12556@psf.upfronthosting.co.za>


Sergei Lebedev <superbobry at gmail.com> added the comment:

> Do you have an example of a /proc entry with st_size == 0 that can be mmapped 
> (mapping /proc/sys/debug/exception-trace fails with EACCESS)?
Yes, I've ran into the issue, while trying to mmap /proc/xen/xsd_kva, which is an 
interface to XenBus [1]. Unfortunately, I'm not aware of any other cases. 

By the way, I've checked mmap(2) manpage -- it looks like the C-version has nothing 
against mmaping 0-sized files, Why does Python's `mmap` still checks file size?

[1] http://wiki.xensource.com/xenwiki/XenBus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:07:23 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Thu, 21 Jul 2011 11:07:23 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1310527759.4.0.117442331882.issue12545@psf.upfronthosting.co.za>
Message-ID: <1311246443.77.0.476283734926.issue12545@psf.upfronthosting.co.za>


Kuberan Naganathan <kubiyak at gmail.com> added the comment:

Hi.  I'm unable ( or have to jump through lots of hoops ) to submit this patch myself for regulatory reasons.  Can someone else submit this please?  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:30:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jul 2011 11:30:13 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311247813.9.0.475763265793.issue12600@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that this is fairly simple to do now via subclassing, so any proposed API would need to show a clear benefit over that approach to be worth the extra complexity in the unittest code base.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:44:57 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 Jul 2011 11:44:57 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311248697.92.0.272444827807.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Note that name clashes *would* result in non-unique testcase ids, so we need to prevent that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:50:02 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jul 2011 11:50:02 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1311249002.69.0.457608279359.issue7879@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please implement name+argtuple first and build auto-naming on top of that.  Nick's approach would not allow me to specify a custom (hand coded) name for each set of arguments, which is my normal use case.  I also would not like the arguments auto-generated into the docstring unless that was optional, since I often have quite substantial argument tuples and it would just clutter the output to have them echoed in the docstring.  In my use cases the custom name is more useful than seeing the actual parameters.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:50:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jul 2011 11:50:20 +0000
Subject: [issue7879] Too narrow platform check in test_datetime
In-Reply-To: <1265580995.55.0.406421096535.issue7879@psf.upfronthosting.co.za>
Message-ID: <1311249020.06.0.154717568598.issue7879@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg140810

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7879>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:51:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jul 2011 11:51:13 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311249073.56.0.510482547504.issue7897@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please implement name+argtuple first and build auto-naming on top of that.  Nick's approach would not allow me to specify a custom (hand coded) name for each set of arguments, which is my normal use case.  I also would not like the arguments auto-generated into the docstring unless that was optional, since I often have quite substantial argument tuples and it would just clutter the output to have them echoed in the docstring.  In my use cases the custom name is more useful than seeing the actual parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:54:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jul 2011 11:54:21 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1311249261.64.0.0878111729574.issue12556@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/issue12556>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:56:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 11:56:33 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

General untidiness in the anchor names (and lack of same for entries like <script>)

Missing incoming:
- from "Invoking the Interpreter" in the tutorial
- direct link from runpy.run_module to -m switch
- direct link from runpy.run_path to <script>

Missing outgoing:
- direct link from <script> to runpy.run_path

Also, zipfile/dir execution was added in 2.6, not 2.5.

----------
messages: 140812
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Missing using docs cross-references

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Thu Jul 21 13:57:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 11:57:06 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1311249426.07.0.368588371518.issue12602@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Thu Jul 21 14:05:05 2011
From: report at bugs.python.org (higery)
Date: Thu, 21 Jul 2011 12:05:05 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311249905.85.0.362129855091.issue12394@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22711/6382acfb1685.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Jul 21 14:10:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 12:10:47 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249426.14.0.91773769342.issue12602@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d+aaKSZGeHTqg3f_71poHZMZjZNoTK6qwALyceZEWcNw@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Should also be an outgoing link to http://bugs.python.org/issue1739468
from the <script> entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Thu Jul 21 14:13:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Jul 2011 12:13:50 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311250430.95.0.714532274625.issue12600@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Note that this is fairly simple to do now via subclassing, so any
> proposed API would need to show a clear benefit over that approach to
> be worth the extra complexity in the unittest code base.

Agreed. Let's not add cruft to unittest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Thu Jul 21 14:33:42 2011
From: report at bugs.python.org (higery)
Date: Thu, 21 Jul 2011 12:33:42 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311251622.79.0.291330813025.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

I hope people can help me test this patch especially on non-Windows platforms.

The main implementation resides in build_scripts.py.

Usage: Just add a 'wrapper-scripts-entries' variable in setup.cfg, which takes a list type as its value. For instance,

wrapper-scripts-entries = ['hello=demo.foo.bar:main']

There is only one entry named 'hello' in current setup.cfg, the 'demo.foo.bar' is the dotted module path, and the 'main' is the main function name which will be called to execute.



Current patch can generte executable script with no extension on POSIX, and .exe file on Windows but have not yet added gui support. 

I also have another problem here looking for help:

In the 'test_command_build_scripts.py', how to test the generated .exe wrapper to see if it can run and generate correct output or not? The only way I can remember is to use os.system(), but if we use os.system() to execute the .exe file, then it will not get the what we want, because it will run in another thread, thus can not get the right sys.path which I have set in my test function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Jul 21 14:52:51 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 Jul 2011 12:52:51 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311252771.03.0.748688245036.issue12600@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Yeah, without some clear advantages and a clean api / implementation I'm -1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Thu Jul 21 14:57:30 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Jul 2011 12:57:30 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311253050.39.0.692240757903.issue12589@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The result of:

struct.pack("d", float("inf"))

would also be interesting.  I'd expect to see:

'\x7f\xf0\x00\x00\x00\x00\x00\x00'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Thu Jul 21 17:26:51 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 21 Jul 2011 15:26:51 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311262011.63.0.82600032911.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

David, I don't understand - it looks like Nick's suggestion would allow you to create a name per case, that's the point of it!

You could even do this:

def _name_from_case(name, cases):
    for idx, case in enumerate(cases, start=1):
        test_name = case[0]
        params = case[1:]
        yield (test_name, params)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 17:47:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jul 2011 15:47:22 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311263242.0.0.895975020237.issue7897@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oh, I see.  Make the name the first element of the argtuple and then strip it off.  Well, that will work, it just seems bass-ackwards to me :)

And why is it 'case'?  I thought we were talking about tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Thu Jul 21 19:04:57 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Thu, 21 Jul 2011 17:04:57 +0000
Subject: [issue10503] os.getuid() documentation should be clear on what kind
	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <1311267897.75.0.920142026709.issue10503@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10503>
_______________________________________

From report at bugs.python.org  Thu Jul 21 19:10:05 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Thu, 21 Jul 2011 17:10:05 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1311268205.4.0.479093098185.issue12436@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Thu Jul 21 19:41:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jul 2011 17:41:08 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <E1QjxFD-00041j-8n@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f5a7d413638d by Charles-Fran?ois Natali in branch '2.7':
Issue #12372: POSIX semaphores are broken on AIX: don't use them.
http://hg.python.org/cpython/rev/f5a7d413638d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Thu Jul 21 19:45:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jul 2011 17:45:38 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <E1QjxJY-0004b5-GF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f0475f78d45c by Charles-Fran?ois Natali in branch '3.2':
Issue #12372: POSIX semaphores are broken on AIX: don't use them.
http://hg.python.org/cpython/rev/f0475f78d45c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Thu Jul 21 19:49:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Jul 2011 17:49:43 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <E1QjxNW-0004uZ-7M@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 44a02d6b74e4 by Charles-Fran?ois Natali in branch 'default':
Merge - Issue #12372: POSIX semaphores are broken on AIX: don't use them.
http://hg.python.org/cpython/rev/44a02d6b74e4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Thu Jul 21 20:01:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 21 Jul 2011 18:01:45 +0000
Subject: [issue12372] semaphore errors on AIX 7.1
In-Reply-To: <1308560168.88.0.791994577012.issue12372@psf.upfronthosting.co.za>
Message-ID: <1311271305.92.0.262229677675.issue12372@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed: this should fix POSIX semaphores failures on AIX.
Reshmi, thanks for reporting this!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12372>
_______________________________________

From report at bugs.python.org  Thu Jul 21 20:57:28 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 21 Jul 2011 18:57:28 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1311274648.79.0.0733336879215.issue12555@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/issue12555>
_______________________________________

From report at bugs.python.org  Thu Jul 21 21:05:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 21 Jul 2011 19:05:09 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1311246172.63.0.917851479965.issue12556@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2MCMUZpGSqmF2p3_H7RwHp6zRfoZMAeCoizyRL_QOo1g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> By the way, I've checked mmap(2) manpage -- it looks like the C-version has
> nothing
> against mmaping 0-sized files, Why does Python's `mmap` still checks file
> size?

It doesn't check explicitely that the size is non-0, but rather that
the offset is is less than the file size.
Passing mmap(2) a 0 length doesn't make much sense anyway - for
example, Linux returns EINVAL:
http://lxr.free-electrons.com/source/mm/mmap.c?a=avr32#L979
"""
unsigned long do_mmap_pgoff(...)
[...]
        if (!len)
                 return -EINVAL;
"""

>> Do you have an example of a /proc entry with st_size == 0 that can be
>> mmapped
>> (mapping /proc/sys/debug/exception-trace fails with EACCESS)?
> Yes, I've ran into the issue, while trying to mmap /proc/xen/xsd_kva, which
> is an
> interface to XenBus [1]. Unfortunately, I'm not aware of any other cases.

That's what I thought, it's really uncommon: in that case, I'm
reluctant to making such a change, for the reason explained above.
Ross, Victor?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Thu Jul 21 21:22:00 2011
From: report at bugs.python.org (Landry Breuil)
Date: Thu, 21 Jul 2011 19:22:00 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311276120.78.0.251799463216.issue12589@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

>>> import struct
>>> struct.pack("d", float("inf"))
b'\x7f\xf0\x00\x00\x00\x00\x00\x00'
>>> struct.pack("f", float("inf"))
b'\x7f\x80\x00\x00'

And yes, HAVE_DECL_ISINF is defined to 1 in pyconfig.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Thu Jul 21 21:39:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jul 2011 19:39:45 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1311277185.95.0.159087393508.issue12581@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/issue12581>
_______________________________________

From report at bugs.python.org  Thu Jul 21 22:33:11 2011
From: report at bugs.python.org (Josh Triplett)
Date: Thu, 21 Jul 2011 20:33:11 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
	(common for filesystems without mtime)
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>


New submission from Josh Triplett <josh at joshtriplett.org>:

In Python 2.7.2, pydoc.py's synopsis contains this code implementing a cache:

    mtime = os.stat(filename).st_mtime
    lastupdate, result = cache.get(filename, (0, None))
    if lastupdate < mtime:

Many filesystems don't have any concept of mtime or don't have it available, including many FUSE filesystems, as well as our implementation of stat for GRUB in BITS.  Such systems typically return an mtime of 0.  (In addition, 0 represents a valid mtime.)  Since the cache in pydoc.synopsis initializes lastupdate to 0 for entries not found in the cache, this causes synopsis to always return None.  I'd suggest either extending the conditional to check "lastupdate != 0 and lastupdate < mtime" (which would always treat an mtime of 0 as requiring an update, which would make sense for filesystems without valid mtimes) or changing the .get to return (None, None) and checking "lastupdate is not None and lastupdate < mtime", which would treat an mtime of 0 as valid but still handle the case of not having a cache entry the first time.

----------
components: Library (Lib)
messages: 140826
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: pydoc.synopsis breaks if filesystem returns mtime of 0 (common for filesystems without mtime)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Thu Jul 21 22:38:14 2011
From: report at bugs.python.org (Josh Triplett)
Date: Thu, 21 Jul 2011 20:38:14 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>


New submission from Josh Triplett <josh at joshtriplett.org>:

In _sre.c, the VTRACE macro normally gets defined to nothing.  It later gets used as the body of control structures such as "else" without braces, which causes many compilers to warn (to catch stray semicolons like "else;").  This makes it difficult to compile Python as part of a project which uses -Werror, such as GRUB.  Please consider defining VTRACE as do {} while(0) instead, as the standard convention for an empty function-like macro with no return value.

----------
messages: 140827
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: VTRACE macro in _sre.c should use do {} while (0)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12604>
_______________________________________

From report at bugs.python.org  Thu Jul 21 23:02:14 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 21 Jul 2011 21:02:14 +0000
Subject: [issue12605] Enhancements to gdb 7 debugging hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I'm attaching patches to handle some more "events" in the gdb7 debugging hooks for CPython (aka Tools/gdb/libpython.py).

Currently, the hooks only care about C frames that are the bytecode interpreter (i.e. PyEval_EvalFrameEx)

This patch changes this, dividing C frames into:
  - "python frames":
    - "bytecode frames" i.e. PyEval_EvalFrameEx
    - "other python frames": C frames that are of interest from a python
      perspective, but aren't bytecode
  - everything else

so that the "py-bt", "py-up" and "py-down" commands will now work on the other kinds of "python" frames, in addition to the bytecode frames.

Specifically, the following new kinds of C frame are displayed:
  - waiting on the GIL
  - garbage-collection
  - CFunctions (these weren't displayed before)

This should assist when debugging multithreaded crashes, to more easily get a sense of what every thread is doing.

Examples:
Showing a garbage-collection:
(gdb) py-bt
  Garbage-collecting
  <built-in method collect of module object at remote 0x7ffff18ea420>
  File "<string>", line 4, in foo
  File "<string>", line 6, in bar
  File "<string>", line 7, in <module>

(gdb) py-bt-full
#1 Garbage-collecting
#2 <built-in method collect of module object at remote 0x7ffff18ea420>
#5 Frame 0x7ffff20d6d48, for file <string>, line 4, in foo ()
#8 Frame 0x7ffff20d6b70, for file <string>, line 6, in bar ()
#11 Frame 0x7ffff7fb1d80, for file <string>, line 7, in <module> ()

Showing an invocation of "time.sleep()":
(gdb) py-bt-full
#0 <built-in method sleep of module object at remote 0x7ffff1af8150>
#3 Frame 0x7ffff18aa060, for file <string>, line 3, in foo ()
#6 Frame 0x7ffff20d6b70, for file <string>, line 5, in bar ()
#9 Frame 0x7ffff7fb1d80, for file <string>, line 6, in <module> ()
  

Showing multiple threads, where all but one are waiting for the GIL:

Thread 5 (Thread 0x7fffeb5fe700 (LWP 10716)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 4 (Thread 0x7fffebfff700 (LWP 10715)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 3 (Thread 0x7ffff0dea700 (LWP 10714)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 2 (Thread 0x7ffff17eb700 (LWP 10713)):
Traceback (most recent call first):
  Waiting for the GIL
  File "<string>", line 10, in run
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap
    self._bootstrap_inner()

Thread 1 (Thread 0x7ffff7fdb700 (LWP 10709)):
Traceback (most recent call first):
  File "<string>", line 18, in <module>

----------
assignee: dmalcolm
components: Demos and Tools
keywords: needs review
messages: 140828
nosy: dmalcolm, haypo
priority: normal
severity: normal
status: open
title: Enhancements to gdb 7 debugging hooks
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12605>
_______________________________________

From report at bugs.python.org  Thu Jul 21 23:05:26 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 21 Jul 2011 21:05:26 +0000
Subject: [issue12605] Enhancements to gdb 7 debugging hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1311282326.43.0.0414433258207.issue12605@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22712/more-frames-in-gdb-hooks-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12605>
_______________________________________

From report at bugs.python.org  Thu Jul 21 23:06:04 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 21 Jul 2011 21:06:04 +0000
Subject: [issue12605] Enhancements to gdb 7 debugging hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1311282364.38.0.441645446354.issue12605@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

(On 2.7, I needed import_site=True to get the new tests to work from a fresh build: "import time" wasn't being found otherwise)

----------
Added file: http://bugs.python.org/file22713/more-frames-in-gdb-hooks-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12605>
_______________________________________

From report at bugs.python.org  Thu Jul 21 23:29:02 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 21 Jul 2011 21:29:02 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1310719010.29.0.524397451586.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E289A1C.8010605@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm still in favor of keeping sys.platform == 'linux3', and you?

Still -1. It should be renamed to 'linux' in future releases, and
back-patched to 'linux2' for maintenance releases.

As for releases that are already out - users should be informed to
not use those on Linux 3 (or not use Linux 3 on systems where they
have the old Python releases).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jul 22 00:15:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 21 Jul 2011 22:15:33 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <4E289A1C.8010605@v.loewis.de>
Message-ID: <CAH_1eM077nD-a-M43FQ7GW5CVc-xbj_jYaZLGf64sHcbi2DzDA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Still -1. It should be renamed to 'linux' in future releases, and
> back-patched to 'linux2' for maintenance releases.
>

I really don't see any advantage to this solution:
- sys.platform currently has a clear and documented value (OS name +
major release), this change would break that
- sys.platform is actually really simple, it returns MACHDEP: this
change would require complicating the code
- code testing sys.platform for equality is already broken: there's
the exact same problem with FreeBSD, OpenBSD and any other operating
system I can think of: 99% of the time, people checking sys.platform
really mean sys.platform.startswith(<OS name>), os.uname()[0] or
platform.system(), i.e. the OS name, and don't care about the release
- this change would introduce an inconsistency between Python
releases, which would make the problem worse
- this information is already provided by os.uname() and platform.system()
- finally, this would not solve the problem at hand

> As for releases that are already out - users should be informed to
> not use those on Linux 3 (or not use Linux 3 on systems where they
> have the old Python releases).
>

Advise users to not use Python on Linux 3 - which doesn't break break
backward compatibility in any way - sounds like a really bad idea, and
would give Python a bad press for no reason.
I mean, it's just a version number, and a really minor bug:
Chromium and matplotlib already fixed this in their code using
sys.platform.startswith('linux') [1] [2].
It's that simple, I don't see what there's so much to talk about here.

[1] http://codereview.chromium.org/7172016
[2] https://github.com/matplotlib/matplotlib/commit/aaef94485cf71ed3181e0adc5577d1a8911f6544

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Jul 22 00:31:35 2011
From: report at bugs.python.org (py.user)
Date: Thu, 21 Jul 2011 22:31:35 +0000
Subject: [issue12606] Mutable Sequence Type works different for lists and
	bytearrays in slice[i:j:k]
In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>
Message-ID: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> barr = bytearray(b'abcde')
>>> lst = list('abcde')
>>> barr[::-3] = ()
>>> barr
bytearray(b'acd')
>>> lst[::-3] = ()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: attempt to assign sequence of size 0 to extended slice of size 2
>>> del lst[::-3]
>>> lst
['a', 'c', 'd']
>>>

lst[::-3] = () - is more convenient way for deletion

----------
components: Interpreter Core
messages: 140832
nosy: py.user
priority: normal
severity: normal
status: open
title: Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k]
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12606>
_______________________________________

From report at bugs.python.org  Fri Jul 22 00:31:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Jul 2011 22:31:54 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1311287514.45.0.235103005181.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file22714/1d8b7f158721.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Fri Jul 22 00:33:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Jul 2011 22:33:32 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1311287612.01.0.453652685255.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file22705/40ae82fafaed.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Fri Jul 22 00:56:29 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Thu, 21 Jul 2011 22:56:29 +0000
Subject: [issue6068] ctypes is not correctly handling bitfields backed by 64
	bit integers on Windows
In-Reply-To: <1242812831.01.0.315764913222.issue6068@psf.upfronthosting.co.za>
Message-ID: <1311288989.51.0.220645409196.issue6068@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Ping? This also fixes 6493 (I believe in a cleaner way)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6068>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:13:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jul 2011 23:13:34 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <CAH_1eM2MCMUZpGSqmF2p3_H7RwHp6zRfoZMAeCoizyRL_QOo1g@mail.gmail.com>
Message-ID: <201107220113.33212.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> That's what I thought, it's really uncommon: in that case, I'm
> reluctant to making such a change, for the reason explained above.
> Ross, Victor?

Why do you want a mmap? Why not using a file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:16:23 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 21 Jul 2011 23:16:23 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1311290183.47.0.584788904992.issue12556@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:18:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Jul 2011 23:18:44 +0000
Subject: [issue12606] Mutable Sequence Type works different for lists and
	bytearrays in slice[i:j:k]
In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>
Message-ID: <1311290324.98.0.843811681376.issue12606@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I happen to prefer del myself, but I agree that the two mutable sequence classes should behave the same. The manual 4.6.4 says

s[i:j:k] = t the elements of s[i:j:k] are replaced by those of t (1) 
1. t must have the same length as the slice it is replacing.

So the list behavior is not a bug. Extending its behavior is a feature request that could only happen in the 'next' release, now 3.3.

It is not usually considered a bug for something to do something beyond what is promised; in any case, you are *not* requesting that bytearrays be restricted as lists are. But that could be the fix to remove the 'bug' of inconsistency.  That also could not happen until a next release.

Since deletion of contiguous slices works and since deletion of extended slices can work and since I found the restriction slightly surprising, I am in favor of extending list behavior unless there is some internal reason why it cannot be.

The rationale for the restriction is that replacing a contiguous slice with a different number of items makes sense but replacing non-contiguous items with a different number does not -- except in the special case where the number is 0. So what you are really asking is that the footnote be changed to

1. t must have the same length as the slice it is replacing or be empty

That is the current behavior of bytearrays.

----------
nosy: +terry.reedy
stage:  -> test needed
type: behavior -> feature request
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12606>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:29:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Jul 2011 23:29:12 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311290952.02.0.766749199172.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You may try:

$ ./python
>>> import ctypes
>>> import ctypes.util
>>> libc = ctypes.cdll.LoadLibrary(ctypes.util.find_library('c'))
>>> isinf = libc.isinf
>>> isinf.argtypes = (ctypes.c_double,)
>>> isinf(0.0)
0
>>> isinf(float('inf'))
1

(try ctypes.util.find_library('m') if isinf is not in libc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:40:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 23:40:49 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311291649.06.0.981469257227.issue7897@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
Removed message: http://bugs.python.org/msg140819

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:41:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 23:41:47 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311291707.41.0.810722885936.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sorry, misclicked and removed this comment from David:

Oh, I see.  Make the name the first element of the argtuple and then strip it off.  Well, that will work, it just seems bass-ackwards to me :)

And why is it 'case'?  I thought we were talking about tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:44:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 21 Jul 2011 23:44:34 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311291874.41.0.41396674389.issue7897@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In my example, I needed a word to cover each entry in the collection of parameter tuples. 'case' fit the bill.

The reason I like the builder approach is that it means the simplest usage is to just create a list (or other iterable) of parameter tuples to be tested, then pass that list to the decorator factory. The sequential naming will then let you find the failing test cases in the sequence.

Custom builders then cover any cases where better naming is possible and desirable (such as explicitly naming each case as part of the parameters).

One refinement that may be useful is for the builders to produce (name, description, parameters) 3-tuple rather than 2-tuples, though. Then the default builder could just insert repr(params) as the description, while David's custom builder could either leave the description blank, or include a relevant subset of the parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:50:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Jul 2011 23:50:02 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1311292202.22.0.698049978668.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Georg, could index directives be used to create link targets?  (see http://bugs.python.org/issue11975#msg137447)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Fri Jul 22 01:51:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Jul 2011 23:51:33 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1311292293.56.0.867387856461.issue11435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the commit, I intended to do it these days.

For 2.7, I was indeed talking about updated all manual links.  sed is my friend :)

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:01:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 00:01:43 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311292903.32.0.304005020956.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great to hear these news!  I will pull from your clone and test on linux2 as soon as possible.

In your Mercurial configuration file, you should set the git option so that diffs can display editions to binary files.  See http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/

> Usage: Just add a 'wrapper-scripts-entries' variable in setup.cfg,
The new scripts feature should reuse the already existing scripts field, in the files section.

> which takes a list type as its value. For instance,
> wrapper-scripts-entries = ['hello=demo.foo.bar:main']
Config files don?t have lists, but they have multi-line values.  See the packaging/setupcfg doc for more info; here?s an example:

  scripts =
      hello = demo.foo.bar.main

(we use dotted paths throughout packaging, not paths with dots and colons, BTW)

> Current patch can generte executable script with no extension on
> POSIX, and .exe file on Windows but have not yet added gui support.
Looks like a great start!  As I said in private email, have a look at the distribute fork of setuptools to see if they have tests for these features.

> In the 'test_command_build_scripts.py', how to test the generated
> .exe wrapper to see if it can run and generate correct output or not?
> The only way I can remember is to use os.system(), but if we use
> os.system() to execute the .exe file, then it will not get the what
> we want, because it will run in another thread, thus can not get the
> right sys.path which I have set in my test function.
os.system runs a process, not a thread.  You should use the subprocess module, it?s better than os.system.  To pass a custom sys.path, set up a PYTHONPATH environment variable in the env argument of subprocess.Popen.  test_sys and test_site have examples of how to use subprocess.

(Before someone suggests using the helpers in test.support, know that I prefer to use only subprocess, to ease the future backport.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:05:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Jul 2011 00:05:15 +0000
Subject: [issue12528] Implement configurable bitfield allocation strategy
In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>
Message-ID: <1311293115.7.0.849289010335.issue12528@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

My review of the patch: http://bugs.python.org/review/12528/show

----------
nosy: +amaury.forgeotdarc
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12528>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:10:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 00:10:43 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311293443.99.0.293155015904.issue7897@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Well, pyflakes will tell you about name clashes within a TestCase
Seen that :)

> (unless you're shadowing a test on a base class which I guess is
> rarely the case)...
That too, in our own test suite (test_list or test_tuple, I have that change in a Subversion or old hg clone somewhere).  I agree about ?rarely?, however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:13:57 2011
From: report at bugs.python.org (Andrew Bennetts)
Date: Fri, 22 Jul 2011 00:13:57 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1311293637.17.0.342880948676.issue7897@psf.upfronthosting.co.za>


Andrew Bennetts <spiv at users.sourceforge.net> added the comment:

You may be interested an existing, unittest-compatible library that provides this: http://pypi.python.org/pypi/testscenarios

----------
nosy: +spiv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:20:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 00:20:45 +0000
Subject: [issue12591] text files returned by subprocess.Popen with
	universal_newlines=True are not iterable
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311294045.74.0.838117678523.issue12591@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/issue12591>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:22:45 2011
From: report at bugs.python.org (py.user)
Date: Fri, 22 Jul 2011 00:22:45 +0000
Subject: [issue12606] Mutable Sequence Type works different for lists and
	bytearrays in slice[i:j:k]
In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>
Message-ID: <1311294165.48.0.234623784374.issue12606@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

> I happen to prefer del myself
> but I agree that the two mutable sequence classes should behave the same.

del is not so flexible as assignement

>>> cmpr = [bytearray(i.encode('ascii')) for i in ('abcd', 'efgh', 'ijkl')]
>>> cmpr
[bytearray(b'abcd'), bytearray(b'efgh'), bytearray(b'ijkl')]
>>> cmpr[0][::-2] = cmpr[1][::2] = cmpr[2][1::2] = ()
>>> cmpr
[bytearray(b'ac'), bytearray(b'fh'), bytearray(b'ik')]
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12606>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:29:54 2011
From: report at bugs.python.org (py.user)
Date: Fri, 22 Jul 2011 00:29:54 +0000
Subject: [issue12606] Mutable Sequence Type works different for lists and
	bytearrays in slice[i:j:k]
In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>
Message-ID: <1311294594.34.0.131955298807.issue12606@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

the former could be like:
del cmpr[0][::-2], cmpr[1][::2], cmpr[2][1::2]

it's ok

how to implement this with del ?
>>> cmpr
[bytearray(b'abcd'), bytearray(b'efgh'), bytearray(b'ijkl')]
>>> cmpr[0][::-2], cmpr[1][::2] = (), cmpr[2][1::2]
>>> cmpr
[bytearray(b'ac'), bytearray(b'jflh'), bytearray(b'ijkl')]
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12606>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:33:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 00:33:58 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311294838.79.0.385578726044.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Failure on POSIX (linux2):

ERROR: test_install_wrapper_scripts (packaging.tests.test_command_build_scripts.BuildScriptsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/packaging/tests/test_command_build_scripts.py", line 64, in test_install_wrapper_scripts
    cmd.run()
  File "Lib/packaging/command/build_scripts.py", line 64, in run
    self._check_entries()
  File "Lib/packaging/command/build_scripts.py", line 81, in _check_entries
    raise PackagingOptionError("your specific entry '%s' does not exist!" % entry)
packaging.errors.PackagingOptionError: your specific entry 'script1=foo.bar.main1.main' does not exist!

If you can?t easily test on POSIX, I?ll investigate later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:44:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 00:44:56 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1311295496.7.0.33605521677.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great.  I?ve been re-reading some old threads in the spirit of ?pth files are evil?, so I wondered whether we could/should avoid them, but I think the criticism was directed against pth files edited after the initial installation, and pth files abusing the format (import causes exec), IOW setuptools? pth files; our current ideas avoid these two problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:48:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jul 2011 00:48:49 +0000
Subject: [issue12591] text files returned by subprocess.Popen with
	universal_newlines=True are not iterable
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311295729.09.0.591807043276.issue12591@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The "universal_newlines" feature is rather poorly named in Python 3.x, since it does much more than that (the resulting files yield and expect unicode strings rather than bytes objects).

The problem is that io.TextIOWrapper needs a buffered I/O object, but bufsize is 0 by default in subprocess.Popen(). In the meantime, you can workaround it using a non-zero bufsize in the Popen() constructor. Of course, this has the side-effect of forcing you to call flush() on the stdin stream (if you are using it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:53:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 00:53:59 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1311296039.29.0.174554739406.issue11435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Georg or Benjamin: The PEP/documents/scripts used for releases should also mention/edit the version in Doc/tools/sphinxext/pyspecific.py.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:58:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 00:58:13 +0000
Subject: [issue12279] Add build_distinfo command to packaging
In-Reply-To: <1307461733.49.0.987510653631.issue12279@psf.upfronthosting.co.za>
Message-ID: <1311296293.01.0.603514817244.issue12279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I kept this report open to address ?test command needs dist-info?, but there?s already a report about that (#12302) and I think it?s clearer to keep this one closed as a discussion archive linked from the develop bug.

----------
resolution: later -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12279>
_______________________________________

From report at bugs.python.org  Fri Jul 22 02:59:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jul 2011 00:59:04 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1311296344.87.0.49638896383.issue11435@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/issue11435>
_______________________________________

From report at bugs.python.org  Fri Jul 22 03:10:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 01:10:46 +0000
Subject: [issue12302] packaging test command needs access to .dist-info
In-Reply-To: <1307660263.81.0.443171517723.issue12302@psf.upfronthosting.co.za>
Message-ID: <1311297046.3.0.966244928806.issue12302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For #8668 (develop command), higery has written code that reuses install_distinfo to create the dist-info dir in the build dir.  It requires #12344, which I will commit when Thomas has time to finish his patch.  We also need to make install_distinfo more flexible: For example, on #12279 we discussed about the RECORD file, which should be empty when created by the test command (nothing is installed), and we mentioned RESOURCES, which should probably be created, with relative paths.  (The resources API is intended to work with zero config in a source checkout or unpacked tarball, even though it currently doesn?t, but given that test runs in the build dir, we?re not in the source dir anymore, so RESOURCES should probably be written.)

----------
dependencies: +Add **kwargs to get_reinitialized_command
nosy: +higery

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12302>
_______________________________________

From report at bugs.python.org  Fri Jul 22 03:13:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 01:13:14 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1311297194.33.0.392787015878.issue12204@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good, with one issue: I?ve never encountered ?cased character? before, is it an accepted term or an invention in our docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Fri Jul 22 03:38:22 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 Jul 2011 01:38:22 +0000
Subject: [issue11055] OS X IDLE 3.2 Save As menu accelerator opens two Save
	windows
In-Reply-To: <1296273818.82.0.517737090521.issue11055@psf.upfronthosting.co.za>
Message-ID: <1311298702.45.0.287574223028.issue11055@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

A fix for this problem has been released in ActiveTcl 8.5.10.1 as of 2011-07-21.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11055>
_______________________________________

From report at bugs.python.org  Fri Jul 22 03:51:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jul 2011 01:51:15 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1311299475.3.0.701056347454.issue12204@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think it's an invention, but its meaning is quite clear to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Fri Jul 22 03:53:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Jul 2011 01:53:15 +0000
Subject: [issue12591] text files returned by subprocess.Popen with
	universal_newlines=True are not iterable
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311299595.39.0.334844999757.issue12591@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So this is a doc bug in subprocess?  Explaining this clearly doesn't sound like much fun...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Fri Jul 22 05:30:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jul 2011 03:30:13 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1311305413.92.0.952371435102.issue12266@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>>> import sys; hex(sys.maxunicode)
'0x10ffff'
>>> import unicodedata; unicodedata.unidata_version
'6.0.0'

import unicodedata
all_chars = list(map(chr, range(0x110000)))
Ll = [c for c in all_chars if unicodedata.category(c) == 'Ll']
Lu = [c for c in all_chars if unicodedata.category(c) == 'Lu']
Lt = [c for c in all_chars if unicodedata.category(c) == 'Lt']
Lo = [c for c in all_chars if unicodedata.category(c) == 'Lo']
Lm = [c for c in all_chars if unicodedata.category(c) == 'Lm']

>>> [len(x) for x in [Ll, Lu, Lt, Lo, Lm]]
[1759, 1436, 31, 97084, 210]
>>> sum(1 for c in Lu if c.lower() == c)
471  # uppercase chars with no lower
>>> sum(1 for c in Lt if c.lower() == c)
0    # titlecase chars with no lower
>>> sum(1 for c in Ll if c.upper() == c)
760  # lowercase chars with no upper
>>> sum(1 for c in Lo if c.upper() != c or c.title() != c or c.lower() != c)
0    # "Letter, other" chars with a different upper/title/lower case
>>> sum(1 for c in Lm if c.upper() != c or c.title() != c or c.lower() != c)
0    # "Letter, modifier" chars with a different upper/title/lower case
>>> sum(1 for c in all_chars if c not in L and (c.upper() != c or c.title() != c or c.lower() != c))
85   # non-letter chars with a different upper/title/lower case
>>> [c for c in all_chars if c not in L and (c.upper() != c or c.title() != c or c.lower() != c)]
['', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?']
>>> list(c.lower() for c in _)
['', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?']
>>> len(_)
85
>>> {unicodedata.category(c) for c in all_chars if c not in L and (c.upper() != c or c.title() != c or c.lower() != c)}
{'So', 'Mn', 'Nl'}

So == Symbol, Other
Mn == Mark, Nonspacing
Nl == Number, Letter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Fri Jul 22 06:26:16 2011
From: report at bugs.python.org (py.user)
Date: Fri, 22 Jul 2011 04:26:16 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1311308776.63.0.169964746213.issue12266@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

>>> [c for c in all_chars if c not in L and ...

L ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Fri Jul 22 06:34:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jul 2011 04:34:09 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1311309249.91.0.755362694956.issue12266@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

L = set(sum([Ll, Lu, Lt, Lo, Lm], []))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Fri Jul 22 06:48:27 2011
From: report at bugs.python.org (Petter Haggholm)
Date: Fri, 22 Jul 2011 04:48:27 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1311310107.31.0.614451239937.issue12581@psf.upfronthosting.co.za>


Petter Haggholm <petter at petterhaggholm.net> added the comment:

Added suggested changes from review, removed (rather useless) repr test; left parse.py changes alone (see review comments for rationale)

----------
Added file: http://bugs.python.org/file22715/urlparsetest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Fri Jul 22 07:11:28 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 22 Jul 2011 05:11:28 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1311311488.76.0.241623818246.issue12556@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> That's what I thought, it's really uncommon: in that case, I'm
> reluctant to making such a change, for the reason explained above.
> Ross, Victor?

Even if Linux did accept a a length of 0 (which it doesn't since 2.6.12), what would be the point? Wouldn't you be mapping *nothing*?

Yeah, I'm against this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Fri Jul 22 07:16:17 2011
From: report at bugs.python.org (Sergei Lebedev)
Date: Fri, 22 Jul 2011 05:16:17 +0000
Subject: [issue12556] Disable size checks in mmap.mmap()
In-Reply-To: <1310649660.01.0.028468381149.issue12556@psf.upfronthosting.co.za>
Message-ID: <1311311777.09.0.628656687856.issue12556@psf.upfronthosting.co.za>


Sergei Lebedev <superbobry at gmail.com> added the comment:

> Passing mmap(2) a 0 length doesn't make much sense anyway - for
example, Linux returns EINVAL.
Yup, but passing mmap(2) a zero-sized file and a non-zero length works just fine.

> Why do you want a mmap? Why not using a file?
Because Xen requires me to mmap it. Anyway, you're right, the use-case is too uncommon.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12556>
_______________________________________

From report at bugs.python.org  Fri Jul 22 07:23:08 2011
From: report at bugs.python.org (Landry Breuil)
Date: Fri, 22 Jul 2011 05:23:08 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311312188.43.0.866742456845.issue12589@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

Python 3.2.1 (default, Jul 18 2011, 10:56:33) 
[GCC 4.2.1 20070719 ] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> import ctypes.util
>>> libc = ctypes.cdll.LoadLibrary(ctypes.util.find_library('c'))
>>> isinf = libc.isinf
>>> isinf.argtypes = (ctypes.c_double,)
>>> isinf(0.0)
0
>>> isinf(float('inf'))
1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 11:46:25 2011
From: report at bugs.python.org (=?utf-8?b?Q2hyaXN0aWFuIEjDpGdnc3Ryw7Zt?=)
Date: Fri, 22 Jul 2011 09:46:25 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>


New submission from Christian H?ggstr?m <pajton at kalvdans.no-ip.org>:

I hit a variant of issue #12251, namely when you redirect both stdout and stderr of a child process and one of them uses a low fd.
Testcase:

import subprocess, sys
subprocess.call(["ls", "asda"], stderr = sys.stdout, stdout = open("/dev/null", "w"))

strace output:

open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
[child process]
dup2(3, 1)   = 1  // overwrites the stdout filedescriptor..
dup2(1, 2)   = 2  // that was supposed to be duped here.
close(3)    = 0   // okay

The testcase is supposed to print "ls: file not found" on stdout, but is silent.

----------
components: Library (Lib)
messages: 140864
nosy: Evgeny.Tarasov, alexey-smirnov, chn, haypo, mmarkk, neologix, r.david.murray
priority: normal
severity: normal
status: open
title: subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Fri Jul 22 12:08:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 10:08:12 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311329292.48.0.726366081785.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem is in PyLong_FromDouble(): if (Py_IS_INFINITY(dval)) is evaluated as false, whereas dval *is* infinity. Possible causes:

 - Py_IS_INFINITY is not defined as "# define Py_IS_INFINITY(X) isinf(X)" (issue with the pyconfig.h file?)
 - the compiler replaces isinf(X) by something else (!?)
 - isinf() is not called with the right argument (conversion between 32, 64 and/or 80 floats?)
 - issue with the FPU mode (unlikely because in your ctypes test, isinf(float("inf")) returns 1, and this test runs in the Python process)

Try to run python in gdb. Set a breakpoint on isinf() (or on PyLong_FromDouble() and use step by step) to check that the function is really called, and called with the "right" argument.

You may also try to replace Py_IS_INFINITY(dval) directly by isinf(dval) (or simply if(1) :-)) in PyLong_FromDouble().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 12:11:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 10:11:23 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311329483.15.0.880329577469.issue12607@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> stdout = open("/dev/null", "w"), stderr = sys.stdout

You ask to write all outputs to /dev/null. Why do you expect anything on stdout?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Fri Jul 22 12:18:35 2011
From: report at bugs.python.org (=?utf-8?b?Q2hyaXN0aWFuIEjDpGdnc3Ryw7Zt?=)
Date: Fri, 22 Jul 2011 10:18:35 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311329915.22.0.893133203587.issue12607@psf.upfronthosting.co.za>


Christian H?ggstr?m <pajton at kalvdans.no-ip.org> added the comment:

I expect that 'ls' print the error message on its stderr, which would be redirected to stdout of the test Python program.

If I had been using stderr = subprocess.STDOUT, I can agree with you that both output streams would go to /dev/null.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Fri Jul 22 13:22:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 11:22:00 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311333720.98.0.886132753121.issue12607@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> stdout = open("/dev/null", "w"), stderr = sys.stdout

Oh, I read subprocess.STDOUT instead of sys.stdout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Fri Jul 22 13:26:17 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 22 Jul 2011 11:26:17 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311333977.34.0.641200283175.issue12607@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

It is indeed a problem.

It seems like the problem comes about due to the "swapping" of fds.
i.e. using stdout as stderr. The reverse appears to work due to the order in which the dup() calls are performed.

Attached is a patch which fixes the issue.

----------
keywords: +patch
nosy: +rosslagerwall
Added file: http://bugs.python.org/file22716/i12607.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Fri Jul 22 13:37:24 2011
From: report at bugs.python.org (Myrosia Dzikovska)
Date: Fri, 22 Jul 2011 11:37:24 +0000
Subject: [issue10026] xml.dom.pulldom strange behavior
In-Reply-To: <1286273854.3.0.24375174829.issue10026@psf.upfronthosting.co.za>
Message-ID: <1311334644.39.0.965510017606.issue10026@psf.upfronthosting.co.za>


Myrosia Dzikovska <myrosia at gmail.com> added the comment:

I have the same problem, and I tried the solution suggested in here, namely expanding the node at END_ELEMENT. It does not work, raising the following exception:

Traceback (most recent call last):
  File "/group/project/onrbee/data/beetle2-eval-09/annotation_tools/logTools/add_start_times.py", line 163, in <module>
    main(sys.argv[1:])
  File "/group/project/onrbee/data/beetle2-eval-09/annotation_tools/logTools/add_start_times.py", line 130, in main
    events.expandNode(node)
  File "/usr/lib/python2.6/site-packages/_xmlplus/dom/pulldom.py", line 248, in expandNode
    parents[-1].appendChild(cur_node)
IndexError: list index out of range


The code fragment was:

  events = xml.dom.pulldom.parse( outName )
    for (event,node) in events:
        if (event == xml.dom.pulldom.END_ELEMENT) and (node.tagName == "message"):
             events.expandNode(node)

----------
nosy: +Myrosia.Dzikovska

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10026>
_______________________________________

From report at bugs.python.org  Fri Jul 22 13:40:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jul 2011 11:40:07 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <E1QkE5N-0003H3-Vf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0752215f9f91 by Eli Bendersky in branch '2.7':
Issue #12434: make StringIO.write error message consistent with Python 2.7 nomenclature
http://hg.python.org/cpython/rev/0752215f9f91

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Fri Jul 22 13:41:20 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 22 Jul 2011 11:41:20 +0000
Subject: [issue12434] Strengthen 2.7 io types warning
In-Reply-To: <1309288978.39.0.732754105333.issue12434@psf.upfronthosting.co.za>
Message-ID: <1311334880.27.0.454546787736.issue12434@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12434>
_______________________________________

From report at bugs.python.org  Fri Jul 22 14:10:11 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 22 Jul 2011 12:10:11 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311336611.56.0.13432946846.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Is the problem happening only on 64-bit Windows, or 32-bit as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:13:27 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:13:27 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

Code:

```
import ast

globalsDict = {}

fAst = ast.FunctionDef(
	name="foo",
	args=ast.arguments(
		args=[], vararg=None, kwarg=None, defaults=[],
		kwonlyargs=[], kw_defaults=[]),
	body=[], decorator_list=[])

exprAst = ast.Interactive(body=[fAst])
ast.fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, globalsDict, globalsDict)

print(globalsDict["foo"])
```

Also CPython 2.6, 2.7, 3.0 and PyPy 1.5 crashes on this.

----------
components: Interpreter Core
messages: 140873
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: crash in PyAST_Compile when running Python code
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12608>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:17:46 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:17:46 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1311340666.11.0.254413372014.issue12608@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

PyPy bug report: https://bugs.pypy.org/issue806

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12608>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:24:31 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Jul 2011 13:24:31 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1311341071.32.0.69770906986.issue12608@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So does default.

----------
nosy: +benjamin.peterson, r.david.murray
type:  -> crash
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12608>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:38:49 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:38:49 +0000
Subject: [issue12609] SystemError: Objects/codeobject.c:64: bad argument to
	internal function
In-Reply-To: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>
Message-ID: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

Code:

```
from ast import *

globalsDict = {}

exprAst = Interactive(body=[FunctionDef(name=u'Py_Main', args=arguments(args=[Name(id=u'argc', ctx=Param()), Name(id=u'argv', ctx=Param())], vararg=None, kwarg=None, defaults=[]), body=[Assign(targets=[Name(id=u'argc', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Name(id=u'argc', ctx=Load()), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'argv', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Name(id=u'argv', ctx=Load()), Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load())], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'c', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'sts', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'command', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'filename', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'module', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'fp', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load()), args=[Num(n=0)], keywords=[], starargs=None, kwargs=None), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load())], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'p', ctx=Store())], value=Call(func=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='POINTER', ctx=Load()), args=[Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_char', ctx=Load())], keywords=[], starargs=None, kwargs=None), args=[], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'unbuffered', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'skipfirstline', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'stdin_is_interactive', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'help_a', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'version', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'saw_unbuffered_flag', ctx=Store())], value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_int', ctx=Load()), args=[Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assign(targets=[Name(id=u'cf', ctx=Store())], value=Call(func=Name(id=u'PyCompilerFlags', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assign', ctx=Load()), args=[Attribute(value=Name(id=u'cf', ctx=Load()), attr=u'cf_flags', ctx=Load()), Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assign', ctx=Load()), args=[Name(id=u'orig_argc', ctx=Load()), Attribute(value=Name(id=u'argc', ctx=Load()), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assignPtr', ctx=Load()), args=[Name(id=u'orig_argv', ctx=Load()), Attribute(value=Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='cast', ctx=Load()), args=[Name(id=u'argv', ctx=Load()), Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_void_p', ctx=Load())], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Expr(value=Call(func=Name(id=u'PySys_ResetWarnOptions', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Attribute(value=Name(id='helpers', ctx=Load()), attr='assign', ctx=Load()), args=[Name(id=u'stdin_is_interactive', ctx=Load()), Attribute(value=Call(func=Name(id=u'Py_FdIsInteractive', ctx=Load()), args=[Num(n=0), Call(func=Attribute(value=Name(id='ctypes', ctx=Load()), attr='c_uint', ctx=Load()), args=[Num(n=0L)], keywords=[], starargs=None, kwargs=None)], keywords=[], starargs=None, kwargs=None), attr='value', ctx=Load())], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Name(id=u'Py_Initialize', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Name(id=u'PySys_SetArgv', ctx=Load()), args=[BinOp(left=Name(id=u'argc', ctx=Load()), op=Sub(), right=Name(id=u'_PyOS_optind', ctx=Load())), BinOp(left=Name(id=u'argv', ctx=Load()), op=Add(), right=Name(id=u'_PyOS_optind', ctx=Load()))], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Assert(test=Name(id='True', ctx=Load()), msg=None), Expr(value=Call(func=Name(id=u'Py_Finalize', ctx=Load()), args=[], keywords=[], starargs=None, kwargs=None)), Assert(test=Name(id='True', ctx=Load()), msg=None), Delete(targets=[Name(id=u'fp', ctx=Del())]), Delete(targets=[Name(id=u'c', ctx=Del())]), Delete(targets=[Name(id=u'version', ctx=Del())]), Delete(targets=[Name(id=u'saw_unbuffered_flag', ctx=Del())]), Delete(targets=[Name(id=u'stdin_is_interactive', ctx=Del())]), Delete(targets=[Name(id=u'cf', ctx=Del())]), Delete(targets=[Name(id=u'argv', ctx=Del())]), Delete(targets=[Name(id=u'filename', ctx=Del())]), Delete(targets=[Name(id=u'p', ctx=Del())]), Delete(targets=[Name(id=u'help_a', ctx=Del())]), Delete(targets=[Name(id=u'command', ctx=Del())]), Delete(targets=[Name(id=u'module', ctx=Del())]), Delete(targets=[Name(id=u'sts', ctx=Del())]), Delete(targets=[Name(id=u'unbuffered', ctx=Del())]), Delete(targets=[Name(id=u'argc', ctx=Del())]), Delete(targets=[Name(id=u'skipfirstline', ctx=Del())])], decorator_list=[])])

fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, {}, globalsDict)

f = globalsDict["Py_Main"]
print(f)
```

This outputs:
SystemError: Objects/codeobject.c:64: bad argument to internal function

PyPy 1.5 outputs:
<function Py_Main at 0x0000000103520610>

I'll try to reduce the test case a bit further.

----------
messages: 140876
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: SystemError: Objects/codeobject.c:64: bad argument to internal function
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12609>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:41:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 13:41:27 +0000
Subject: [issue12609] SystemError: Objects/codeobject.c:64: bad argument to
	internal function
In-Reply-To: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>
Message-ID: <1311342087.93.0.452620294914.issue12609@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/issue12609>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:49:50 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:49:50 +0000
Subject: [issue12610] Fatal Python error: non-string found in code slot
In-Reply-To: <1311342590.28.0.333956728566.issue12610@psf.upfronthosting.co.za>
Message-ID: <1311342590.28.0.333956728566.issue12610@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

Code:

```
from ast import *

globalsDict = {}

body = [
	Assign(targets=[Name(id=u'argc', ctx=Store())],
		   value=Name(id=u'None', ctx=Load())),
	]

exprAst = Interactive(body=[
	FunctionDef(
		name='foo',
		args=arguments(args=[Name(id=u'argc', ctx=Param()), Name(id=u'argv', ctx=Param())],
					   vararg=None, kwarg=None, defaults=[]),
		body=body,
		decorator_list=[])])

fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, {}, globalsDict)

f = globalsDict["foo"]
print(f)
```

CPython 2.7.1: Fatal Python error: non-string found in code slot
PyPy 1.5: <function foo at 0x0000000103114430>

----------
messages: 140877
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: Fatal Python error: non-string found in code slot
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12610>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:52:29 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 22 Jul 2011 13:52:29 +0000
Subject: [issue12609] SystemError: Objects/codeobject.c:64: bad argument to
	internal function
In-Reply-To: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>
Message-ID: <1311342749.88.0.097321669624.issue12609@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

Simplified code:

```
from ast import *

globalsDict = {}

exprAst = Interactive(body=[
	FunctionDef(
		name=u'foo',
		args=arguments(args=[], vararg=None, kwarg=None, defaults=[]),
		body=[Pass()],
		decorator_list=[])])

fix_missing_locations(exprAst)
compiled = compile(exprAst, "<foo>", "single")
eval(compiled, {}, globalsDict)

f = globalsDict["foo"]
print(f)
```

If I change `name=u'foo'` to `name='foo'`, it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12609>
_______________________________________

From report at bugs.python.org  Fri Jul 22 15:57:34 2011
From: report at bugs.python.org (=?utf-8?b?Q2hyaXN0aWFuIEjDpGdnc3Ryw7Zt?=)
Date: Fri, 22 Jul 2011 13:57:34 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311343054.48.0.372460761278.issue12607@psf.upfronthosting.co.za>


Christian H?ggstr?m <pajton at kalvdans.no-ip.org> added the comment:

Thanks for the patch, I haven't tried it (I'm still on Python 2.7) but it looks very special-cased to my case. I can think about exotic cases like

stdin = sys.stderr, stdout = sys.stdin, stderr = sys.stdout

It can happen in reality if a daemon have closed stdio (see bug 10806) and reusing fd's 0,1,2 for other purposes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Fri Jul 22 16:07:45 2011
From: report at bugs.python.org (Darren Dale)
Date: Fri, 22 Jul 2011 14:07:45 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1311343665.1.0.754931914897.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

I've requested additional feedback based on comments at Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri Jul 22 16:22:05 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Fri, 22 Jul 2011 14:22:05 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1311344525.54.0.39434488756.issue12436@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

So what we're looking for is comprehensive HOWTOs for installing and running Python on Windows, OSX and Linux to be added to http://docs.python.org/howto/index.html?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Jul 22 16:26:41 2011
From: report at bugs.python.org (higery)
Date: Fri, 22 Jul 2011 14:26:41 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1311294838.79.0.385578726044.issue12394@psf.upfronthosting.co.za>
Message-ID: <CAHGir+GF9JrL1KruzuYqxSza0xCcFqGJJ-kwEO=V0JEV1eRgTA@mail.gmail.com>


higery <shoulderhigher at gmail.com> added the comment:

>>packaging.errors.PackagingOptionError: your specific entry 'script1=foo.bar.main1.main' does not exist!

I think you did not get the latest version of my code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jul 22 16:48:41 2011
From: report at bugs.python.org (higery)
Date: Fri, 22 Jul 2011 14:48:41 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <CAHGir+GF9JrL1KruzuYqxSza0xCcFqGJJ-kwEO=V0JEV1eRgTA@mail.gmail.com>
Message-ID: <CAHGir+H9dMueOAA58Pa2QyFD8N9d50p_7HKoQTxotq+oRtkbhg@mail.gmail.com>


higery <shoulderhigher at gmail.com> added the comment:

>>In your Mercurial configuration file, you should set the git option so that diffs can display editions to binary files.  See http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/

Thanks.

>>The new scripts feature should reuse the already existing scripts field, in the files section.

But they have different string syntax, old scripts field just uses a
path string as a valid value, eg. 'demo/script.py', while our
wrapper-scripts field uses a kind of '=' separated value, eg.
'hello=demo.script.main'.

>>Looks like a great start!  As I said in private email, have a look at the distribute fork of setuptools to see if they have tests for these features.

OK.

2011/7/22, higery <shoulderhigher at gmail.com>:
>>>packaging.errors.PackagingOptionError: your specific entry
>>> 'script1=foo.bar.main1.main' does not exist!
>
>
> I think you did not get the latest version of my code.
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:01:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jul 2011 15:01:42 +0000
Subject: [issue12609] SystemError: Objects/codeobject.c:64: bad argument to
	internal function
In-Reply-To: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>
Message-ID: <1311346902.91.0.0335213154721.issue12609@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/issue12609>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:01:57 2011
From: report at bugs.python.org (Landry Breuil)
Date: Fri, 22 Jul 2011 15:01:57 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311346917.65.0.145678127976.issue12589@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

$grep -r '#define Py_IS_INF' .
PC/pyconfig.h:#define Py_IS_INFINITY(X) (!_finite(X) && !_isnan(X))


>>> isinf(float('inf'))

Breakpoint 2, __isinf (d=1.0604798301039825e-314) at /usr/src/lib/libc/gen/isinf.c:30
30      in /usr/src/lib/libc/gen/isinf.c
(gdb) bt
#0  __isinf (d=1.0604798301039825e-314) at /usr/src/lib/libc/gen/isinf.c:30
#1  0x8fe528d8 in ffi_call_SYSV () from /usr/local/lib/libffi.so.0.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:02:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jul 2011 15:02:43 +0000
Subject: [issue12610] Fatal Python error: non-string found in code slot
In-Reply-To: <1311342590.28.0.333956728566.issue12610@psf.upfronthosting.co.za>
Message-ID: <1311346963.86.0.589338648662.issue12610@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/issue12610>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:09:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 15:09:37 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1311347377.44.0.610013535704.issue12436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IMO we don?t need HOWTOs that duplicate existing docs, but we may need additions to the existing tutorial and ?using? docs.  See http://bugs.python.org/issue12436#msg140141

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:14:49 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Jul 2011 15:14:49 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311347689.96.0.340631607422.issue12589@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The '1.06...e-314' number in the gdb output is interesting:  it indicates a byte-ordering issue, though maybe that issue is only pertinent to gdb itself.

On a little-endian machine:

>>> struct.pack('<d', 1.0604798301039825e-314)
'\x00\x00\xf0\x7f\x00\x00\x00\x00'
>>> struct.pack('<d', float('inf'))
'\x00\x00\x00\x00\x00\x00\xf0\x7f'

Same bytes, different order.  This may indicate some kind of float / double mismatch somewhere, or a byte-ordering issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:21:37 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Jul 2011 15:21:37 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311348097.12.0.342373978469.issue12589@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Question: does this test also fail after configuring with the --with-pydebug flag?  (Which I *think* should turn compiler optimizations off, amongst other things.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:28:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 15:28:03 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311348483.21.0.300907746096.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> $grep -r '#define Py_IS_INF' .
> PC/pyconfig.h:#define Py_IS_INFINITY(X) (!_finite(X) && !_isnan(X))

The PC/ directory is specific to Windows. Py_IS_INFINITY should be defined in Include/pymath.h (at least, in the 3.2 branch)

> Breakpoint 2, __isinf (d=1.0604798301039825e-314)
> ...
> #1  0x8fe528d8 in ffi_call_SYSV () from /usr/local/lib/libffi.so.0.0

Ah, you ran gdb on ctypes. I forgot to specify that you should run gdb on "int(float('inf'))" instruction in Python, sorry. I would like to check int(float), not ctypes ;-)

If gdb has an endian issue, you may also try "print /x d" in the gdb shell.

Example on x86_64:
---------------------------------------------
$ gdb ./python 
GNU gdb (GDB) 7.1-ubuntu
...
(gdb) run
<press ^C>
(gdb) b isinf
Breakpoint 1 at 0xb7f94f16: file ../sysdeps/ieee754/dbl-64/s_isinf.c, line 23. (2 locations)
(gdb) cont
>>> int(float('inf'))

Breakpoint 1, *__GI___isinf (x=inf) at ../sysdeps/ieee754/dbl-64/s_isinf.c:23
23	../sysdeps/ieee754/dbl-64/s_isinf.c: Aucun fichier ou dossier de ce type.
	in ../sysdeps/ieee754/dbl-64/s_isinf.c
(gdb) print /x x
$1 = 0x8000000000000000

(gdb) where
#0  *__GI___isinf (x=inf) at ../sysdeps/ieee754/dbl-64/s_isinf.c:23
#1  0x0819b03e in PyLong_FromDouble (dval=inf) at Objects/longobject.c:280
#2  0x0818d660 in float_trunc (v=<float at remote 0x826fb44>) at Objects/floatobject.c:896
#3  0x081619c6 in PyNumber_Long (o=<float at remote 0x826fb44>) at Objects/abstract.c:1348
#4  0x081a4823 in long_new (type=0x824b420, args=(<float at remote 0x826fb44>,), kwds=0x0) at Objects/longobject.c:4130
...
(gdb) frame 1
#1  0x0819b03e in PyLong_FromDouble (dval=inf) at Objects/longobject.c:280
280	    if (Py_IS_INFINITY(dval)) {
(gdb) print /x dval
$2 = 0x8000000000000000
---------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:30:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 15:30:16 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311348616.9.0.181246008383.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If gdb has an endian issue,
> you may also try "print /x d" in the gdb shell.

Oh, forget me: /x converts the argument to an integer...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:24:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 15:24:30 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311348270.37.0.776920409024.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think you did not get the latest version of my code.
I pulled and updated again and got a different error :)

ERROR: test_install_wrapper_scripts (packaging.tests.test_command_build_scripts.BuildScriptsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/packaging/tests/test_command_build_scripts.py", line 79, in test_install_wrapper_scripts
    with open(script, "rb") as f:
IOError: [Errno 13] Permission denied: '/tmp/user/1013/tmp2xp9qc/tmpwhzzmg/script1'

(/tmp/user/1013 is my $TMP directory)

>> The new scripts feature should reuse the already existing scripts
>> field, in the files section.
> But they have different string syntax

Yes, you will have to update the config file parsing code in config, code that uses dist.scripts, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:47:49 2011
From: report at bugs.python.org (Landry Breuil)
Date: Fri, 22 Jul 2011 15:47:49 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311349669.8.0.460277592039.issue12589@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

Py_IS_INFINITY is defined as

#ifndef Py_IS_INFINITY
#  if defined HAVE_DECL_ISINF && HAVE_DECL_ISINF == 1
#    define Py_IS_INFINITY(X) isinf(X)
#  else
#    define Py_IS_INFINITY(X) ((X) &&                                   \
                               (Py_FORCE_DOUBLE(X)*0.5 == Py_FORCE_DOUBLE(X)))
#  endif
#endif


The test still fails when built --with-pydebug.

(gdb)  b isinf 
Function "isinf" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (isinf) pending.
(gdb) r
Starting program: /usr/obj/ports/Python-3.2.1/Python-3.2.1/python 
Breakpoint 2 at 0x852786d4: file /usr/src/lib/libc/gen/isinf.c, line 27.
Pending breakpoint "isinf" resolved
Python 3.2.1 (default, Jul 22 2011, 17:34:54) 
[GCC 4.2.1 20070719 ] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> int(float('inf'))
0
[56408 refs]

isinf is #defined in math.h to

#define isinf(x) \
        ((sizeof (x) == sizeof (float)) ? \
                __isinff(x) \
        : (sizeof (x) == sizeof (double)) ? \
                __isinf(x) \
        :       __isinfl(x))

but setting a bkp on it changes nothing.

Starting program: /usr/obj/ports/Python-3.2.1/Python-3.2.1/python 
Breakpoint 2 at 0x89b4f708: file /usr/src/lib/libc/gen/isinf.c, line 36.
Pending breakpoint "__isinff" resolved
Python 3.2.1 (default, Jul 22 2011, 17:34:54) 
[GCC 4.2.1 20070719 ] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> int(float('inf'))
0

Setting a bkp on PyLong_FromDouble() shows that it's not called.

Sorry, this doesnt make sense to me...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:53:02 2011
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 22 Jul 2011 15:53:02 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

2to3 crashes when run on a doctest which uses reduce(). This happens with both 2.7 and 3.2's 2to3. I have the following code in a compatibility file, but even using that it fails with the same error: 

try:
    from functools import reduce
except ImportError:
    reduce = reduce

This is the traceback produced:

Traceback (most recent call last):
  File "/usr/local/bin/2to3", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/usr/local/lib/python2.6/lib2to3/main.py", line 173, in main
    options.processes)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 620, in refactor
    items, write, doctests_only)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 275, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 661, in refactor_file
    *args, **kwargs)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 321, in refactor_file
    output = self.refactor_docstring(input, filename)
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 500, in refactor_docstring
    indent, filename))
  File "/usr/local/lib/python2.6/lib2to3/refactor.py", line 530, in refactor_doctest
    assert clipped == [u"\n"] * (lineno-1), clipped
AssertionError: [u'from functools import reduce\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n', u'\n']

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 140892
nosy: VPeric
priority: normal
severity: normal
status: open
title: 2to3 crashes when converting doctest using reduce()
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12611>
_______________________________________

From report at bugs.python.org  Fri Jul 22 17:55:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jul 2011 15:55:23 +0000
Subject: [issue12609] SystemError: Objects/codeobject.c:64: bad argument to
	internal function
In-Reply-To: <1311341929.92.0.631555163779.issue12609@psf.upfronthosting.co.za>
Message-ID: <E1QkI4Q-000227-3Z@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a21829180423 by Benjamin Peterson in branch '2.7':
verify the types of AST strings and identifiers (closes #12609 and #12610)
http://hg.python.org/cpython/rev/a21829180423

New changeset 3301689bd78d by Benjamin Peterson in branch '3.2':
type check AST strings and identifiers
http://hg.python.org/cpython/rev/3301689bd78d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12609>
_______________________________________

From report at bugs.python.org  Fri Jul 22 18:04:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 16:04:26 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1311350666.52.0.0807311712815.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm not sure that your version of gdb understands macros. You may have to set a breakpoint on __isinf. Compile Python with "-g -ggdb" helps gdb.

Py_IS_INFINITY is may not defined as "# define Py_IS_INFINITY(X) isinf(X)". To check that, add #error macro in pymath.h for all cases around #ifndef Py_IS_INFINITY. For example:

#ifndef Py_IS_INFINITY
#  if defined HAVE_DECL_ISINF && HAVE_DECL_ISINF == 1
#    error "Py_IS_INFINITY is implemented using isinf()"
#    define Py_IS_INFINITY(X) isinf(X)
#  else
#    error "Py_IS_INFINITY is implemented using *0.5"
#    define Py_IS_INFINITY(X) ((X) &&                                   \
                               (Py_FORCE_DOUBLE(X)*0.5 == Py_FORCE_DOUBLE(X)))
#  endif
#else
#  error "Py_IS_INFINITY already set!?"
#endif

And recompile Python. It may be a typo in pyconfig.h (generated by configure) or an issue with the inclusion paths of gcc (-I options).

Can you please attach your pyconfig.h and /usr/include/math.h files?

Can you also copy-paste the line used to compile Object/floatobject.c (to check the compiler options)? Use touch Object/floatobject.c && make to recompile this file.

FYI, isinf() is also a macro on Linux:

# ifdef __NO_LONG_DOUBLE_MATH
#  define isinf(x) \
     (sizeof (x) == sizeof (float) ? __isinff (x) : __isinf (x))
# else
#  define isinf(x) \
     (sizeof (x) == sizeof (float)					      \
      ? __isinff (x)							      \
      : sizeof (x) == sizeof (double)					      \
      ? __isinf (x) : __isinfl (x))
# endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Jul 22 18:09:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Jul 2011 16:09:50 +0000
Subject: [issue12610] Fatal Python error: non-string found in code slot
In-Reply-To: <1311342590.28.0.333956728566.issue12610@psf.upfronthosting.co.za>
Message-ID: <1311350990.84.0.62310121693.issue12610@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> SystemError: Objects/codeobject.c:64: bad argument to internal function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12610>
_______________________________________

From report at bugs.python.org  Fri Jul 22 18:36:11 2011
From: report at bugs.python.org (Paul Price)
Date: Fri, 22 Jul 2011 16:36:11 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>


New submission from Paul Price <price at astro.princeton.edu>:

I am running Python 2.7.1 under Valgrind 3.6.1 on a x86_64 GNU/Linux box.  Valgrind is flagging errors that are not covered by the standard suppressions file (Misc/valgrind-python.supp; after uncommenting the part I'm supposed to), e.g.:

==5804== Use of uninitialised value of size 8
==5804==    at 0x4EBA956: PyObject_Free (obmalloc.c:958)
==5804==    by 0x4E85D65: code_dealloc (codeobject.c:317)
==5804==    by 0x4ECE23C: tupledealloc (tupleobject.c:220)
==5804==    by 0x4E85E42: code_dealloc (codeobject.c:308)
==5804==    by 0x4F3315D: load_source_module (import.c:1022)
==5804==    by 0x4F33F7E: import_submodule (import.c:2596)
==5804==    by 0x4F3420E: load_next (import.c:2416)
==5804==    by 0x4F3484F: import_module_level (import.c:2137)
==5804==    by 0x4F34DA3: PyImport_ImportModuleLevel (import.c:2189)
==5804==    by 0x4F16ABE: builtin___import__ (bltinmodule.c:49)
==5804==    by 0x4E6DA42: PyObject_Call (abstract.c:2529)
==5804==    by 0x4F16F82: PyEval_CallObjectWithKeywords (ceval.c:3881)

==5804== Use of uninitialised value of size 8
==5804==    at 0x4EBA956: PyObject_Free (obmalloc.c:958)
==5804==    by 0x4E85D65: code_dealloc (codeobject.c:317)
==5804==    by 0x4F3315D: load_source_module (import.c:1022)
==5804==    by 0x4F33F7E: import_submodule (import.c:2596)
==5804==    by 0x4F3420E: load_next (import.c:2416)
==5804==    by 0x4F3484F: import_module_level (import.c:2137)
==5804==    by 0x4F34DA3: PyImport_ImportModuleLevel (import.c:2189)
==5804==    by 0x4F16ABE: builtin___import__ (bltinmodule.c:49)
==5804==    by 0x4E6DA42: PyObject_Call (abstract.c:2529)
==5804==    by 0x4F16F82: PyEval_CallObjectWithKeywords (ceval.c:3881)
==5804==    by 0x4F1ACD3: PyEval_EvalFrameEx (ceval.c:2332)
==5804==    by 0x4F1F347: PyEval_EvalCodeEx (ceval.c:3252)

etc.

Perhaps the suppressions file covers only 32-bit machines, because if I add:

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Addr8
   fun:PyObject_Free
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Value8
   fun:PyObject_Free
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Addr8
   fun:PyObject_Realloc
}

{
   ADDRESS_IN_RANGE/Use of uninitialised value of size 8
   Memcheck:Value8
   fun:PyObject_Realloc
}

(i.e., "Value8" instead of "Value4") then all is clear.

----------
components: None
messages: 140895
nosy: Paul.Price
priority: normal
severity: normal
status: open
title: Valgrind suppressions
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12612>
_______________________________________

From report at bugs.python.org  Fri Jul 22 18:42:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 16:42:42 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1311352962.39.0.604545391816.issue12612@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/issue12612>
_______________________________________

From report at bugs.python.org  Fri Jul 22 18:47:05 2011
From: report at bugs.python.org (Qiang Sun)
Date: Fri, 22 Jul 2011 16:47:05 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311353225.73.0.294336464321.issue12540@psf.upfronthosting.co.za>


Qiang Sun <sunqiang at gmail.com> added the comment:

I can reproduce this in 32-bit Windows XP Pro. SP3

----------
nosy: +sunqiang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Fri Jul 22 18:49:32 2011
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 22 Jul 2011 16:49:32 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

The itertools fixer (izip -> zip, among others), fails for the following code:

from itertools import izip
print msg % str(bool(symbol_swapped) and list(izip(*swap_dict).next()) or symbols)

It gets converted to:

print(msg % str(bool(symbol_swapped) and list(next(izip(*swap_dict))) or symbols))

(note how izip is still there)

I've worked aroudn this by introducing tmp = izip(...) and using that, but it'd be nice if 2to3 caught it by default.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 140897
nosy: VPeric
priority: normal
severity: normal
status: open
title: itertools fixer fails
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12613>
_______________________________________

From report at bugs.python.org  Fri Jul 22 18:56:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Jul 2011 16:56:09 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1311353769.77.0.828527974233.issue12613@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12613>
_______________________________________

From report at bugs.python.org  Fri Jul 22 19:32:46 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 22 Jul 2011 17:32:46 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1311355966.27.0.440848581802.issue12608@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/issue12608>
_______________________________________

From report at bugs.python.org  Fri Jul 22 19:33:16 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 22 Jul 2011 17:33:16 +0000
Subject: [issue12599] Use 'is not None' where appropriate in importlib
In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za>
Message-ID: <1311355996.6.0.919809707269.issue12599@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/issue12599>
_______________________________________

From report at bugs.python.org  Fri Jul 22 19:51:27 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 22 Jul 2011 17:51:27 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

Currently urllib.request.Request decides if it's a "GET" or "POST" by the presence of data. However sometimes you want to do an "POST" request without data (in my case, it Crucible REST API). Or provide another method. The attached patched added a `method` argument to Request __init__.

----------
files: request-method.diff
keywords: patch
messages: 140898
nosy: tebeka
priority: normal
severity: normal
status: open
title: Allow to explicitly set the method of urllib.request.Request
versions: Python 3.2
Added file: http://bugs.python.org/file22717/request-method.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Fri Jul 22 19:51:34 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 22 Jul 2011 17:51:34 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311357094.47.0.892954351064.issue12614@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Fri Jul 22 19:51:42 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 22 Jul 2011 17:51:42 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311357102.99.0.615987955338.issue12614@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Fri Jul 22 19:55:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 22 Jul 2011 17:55:37 +0000
Subject: [issue12599] Use 'is not None' where appropriate in importlib
In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za>
Message-ID: <1311357337.41.0.688236409795.issue12599@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12599>
_______________________________________

From report at bugs.python.org  Fri Jul 22 20:00:22 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Fri, 22 Jul 2011 18:00:22 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311357622.46.0.362873251043.issue12614@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Fri Jul 22 20:04:16 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 22 Jul 2011 18:04:16 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1311357856.08.0.836125681127.issue12604@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch against 2.7 that adds the suggested fix.

----------
keywords: +patch
nosy: +petri.lehtinen
Added file: http://bugs.python.org/file22718/fix_empty_macro.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12604>
_______________________________________

From report at bugs.python.org  Fri Jul 22 20:05:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 22 Jul 2011 18:05:09 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1311357909.07.0.743203743351.issue12604@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
components: +Build, Library (Lib)
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12604>
_______________________________________

From report at bugs.python.org  Fri Jul 22 20:05:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 18:05:16 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311357916.56.0.569496785336.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Good question.
Peter, you said Vista x64. Are you running 32 or 64 bit Python?

My system with the apparently irreversible problem is 32 bit xp home.
I am reluctant to test on my daughter's 64 bit laptop as I do not know that I would be able to revert successfully and I want her to be able to write small programs for schoolwork without extra hassle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Fri Jul 22 20:07:51 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 22 Jul 2011 18:07:51 +0000
Subject: [issue12606] Mutable Sequence Type works different for lists and
	bytearrays in slice[i:j:k]
In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za>
Message-ID: <1311358071.42.0.617950399655.issue12606@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12606>
_______________________________________

From report at bugs.python.org  Fri Jul 22 20:35:12 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 22 Jul 2011 18:35:12 +0000
Subject: [issue12615] add array.zeroes
In-Reply-To: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>
Message-ID: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>


New submission from Alex Gaynor <alex.gaynor at gmail.com>:

>From python-ideas:

introduce array.zeroes, a new classmethod that provides an alternative constructor, its signature is zeroes(typecode, length), which allows for preallocating an array, with a lower overhead than methods such as array(typecode, [0]) * length, and is more readable (plus consistant with the numpy method of the same name).

----------
assignee: alex
components: Library (Lib)
messages: 140901
nosy: alex
priority: normal
severity: normal
status: open
title: add array.zeroes
type: feature request
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12615>
_______________________________________

From report at bugs.python.org  Fri Jul 22 21:40:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 19:40:04 +0000
Subject: [issue6669] TarFile.getmembers fails at struct.unpack: unpack
	requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1311363604.33.0.214166270352.issue6669@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________

From report at bugs.python.org  Fri Jul 22 21:44:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 19:44:01 +0000
Subject: [issue4506] 3.0 make test failures on Solaris 10
In-Reply-To: <18742.62305.106334.384352@montanaro-dyndns-org.local>
Message-ID: <1311363841.78.0.806701665551.issue4506@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This appears to be fixed.

Skip: keywords now has a '-no selection-' option to get rid of keywords

----------
keywords:  -64bit
nosy: +terry.reedy
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4506>
_______________________________________

From report at bugs.python.org  Fri Jul 22 21:45:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 19:45:05 +0000
Subject: [issue10760] tarfile doesn't handle sysfs well
In-Reply-To: <1293037554.87.0.808780630488.issue10760@psf.upfronthosting.co.za>
Message-ID: <1311363905.24.0.761185873783.issue10760@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10760>
_______________________________________

From report at bugs.python.org  Fri Jul 22 21:45:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 19:45:42 +0000
Subject: [issue10436] tarfile.extractfile in "r|" stream mode fails with
	filenames or members from getmembers()
In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>
Message-ID: <1311363942.11.0.253792869581.issue10436@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10436>
_______________________________________

From report at bugs.python.org  Fri Jul 22 21:57:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 22 Jul 2011 19:57:53 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311364673.68.0.367035876566.issue12614@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Fri Jul 22 22:02:04 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 22 Jul 2011 20:02:04 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1311364924.79.0.596093091686.issue12170@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

This affects bytearray as well as bytes.

What comes to supporting integer argument to str methods, I'm -1 on that. str's "contained items" are strings of length 1.

----------
title: Bytes.index() and bytes.count() should accept byte ints -> index() and count() methods of bytes and bytearray should accept byte ints
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Fri Jul 22 22:35:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Jul 2011 20:35:06 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <1311149926.15.0.754151765935.issue12545@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2eh0io5_Bi-1KP2NZn8mfq8ndE=JOinsHBb2fs-yN_RQ@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Patch attached.

> For lseek, we can rely on errno. Try something like that:
>
> errno = 0;
> offset = lseek(...);
> if (offset == (off_t)-1 && errno) /* error */
>

It's a little bit overkill :-) (for mktime, time_t can overflow easily
on 32-bit).

> We can write a test using a sparse file... Or maybe a mmap object?
>

I'm not sure it's easily testable, because it's really a corner case
not addressed by POSIX. On my Linux box, I can't get lseek to return a
negative value, I get EINVAL - which does make sense (the Linux kernel
doesn't accept or return negative file offsets, see
http://lwn.net/Articles/138063/).

Kuberan, on what operating system did you notice this problem? Solaris?

----------
keywords: +patch
Added file: http://bugs.python.org/file22719/lseek_negative.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________
-------------- next part --------------
diff -r d3f0f72c31f8 Modules/_io/fileio.c
--- a/Modules/_io/fileio.c	Fri Jul 22 11:10:43 2011 -0500
+++ b/Modules/_io/fileio.c	Fri Jul 22 22:33:54 2011 +0200
@@ -823,7 +823,7 @@
         Py_END_ALLOW_THREADS
     } else
         res = -1;
-    if (res < 0)
+    if (res == -1)
         return PyErr_SetFromErrno(PyExc_IOError);
 
 #if defined(HAVE_LARGEFILE_SUPPORT)
diff -r d3f0f72c31f8 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Fri Jul 22 11:10:43 2011 -0500
+++ b/Modules/posixmodule.c	Fri Jul 22 22:33:54 2011 +0200
@@ -6257,7 +6257,7 @@
     res = lseek(fd, pos, how);
 #endif
     Py_END_ALLOW_THREADS
-    if (res < 0)
+    if (res == -1)
         return posix_error();
 
 #if !defined(HAVE_LARGEFILE_SUPPORT)

From report at bugs.python.org  Fri Jul 22 22:55:15 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Jul 2011 20:55:15 +0000
Subject: [issue12615] add array.zeroes
In-Reply-To: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>
Message-ID: <1311368115.65.0.200369209804.issue12615@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1

Array's API much more closely matches that of list than it does numpy's arrays which are profoundly different.  So we should stick the one-way-to-do-it idiom:  array.array('c', '\0') * 100 or array.array('d', [0.0]) * 100.

Also, the current idiom is much more flexible in that it works with any initializer, not just a zero (compare with numpy's ones() constructor for example).

----------
assignee: alex -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12615>
_______________________________________

From report at bugs.python.org  Fri Jul 22 22:55:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Jul 2011 20:55:21 +0000
Subject: [issue12592] modify configure.in to detect OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <1311368121.98.0.94850275273.issue12592@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch attached (this one should also work with future major releases).

----------
keywords: +needs review, patch
nosy: +neologix, pitrou
stage:  -> patch review
Added file: http://bugs.python.org/file22720/configure_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12592>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:02:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jul 2011 21:02:58 +0000
Subject: [issue12592] modify configure.in to detect OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <1311368578.15.0.286065086625.issue12592@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks fine to me.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12592>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:15:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:15:24 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311369324.82.0.46728726764.issue12614@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  I have made one comment on Rietveld.

----------
assignee:  -> orsenthil
nosy: +eric.araujo, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:18:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:18:36 +0000
Subject: [issue12599] Use 'is not None' where appropriate in importlib
In-Reply-To: <1311204866.94.0.868144642715.issue12599@psf.upfronthosting.co.za>
Message-ID: <1311369516.09.0.473337617415.issue12599@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/issue12599>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:19:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:19:04 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1311369544.31.0.683975164358.issue12613@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12613>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:19:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:19:56 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1311369596.21.0.849833397356.issue12611@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson, eric.araujo
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12611>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:27:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:27:29 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1311370049.13.0.18401223334.issue12602@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> 
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:29:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Jul 2011 21:29:31 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311370171.25.0.706646359804.issue12588@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Previous frame inner to this frame (corrupt stack?)

Interesting.

Could you post the result of:

$ valgrind --tool=memcheck --suppressions=Misc/valgrind-python.supp Modules/_testembed

after having un-commented the ADDRESS_IN_RANGE suppressions from Misc/valgrind-python.supp?

What compiler version are you using?
Could you try compiling with -O0, then with -fstack-protector-all?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:33:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:33:30 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311370410.9.0.883424287971.issue12603@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi!  Thanks for the report and patch ideas.  Would both of your fix ideas preserve backward compatibility?  If yes, we should take the one that makes the code easier to read; if no, we should take the most compatible.  Would you be interested in making a patch?  If so, helpful guidelines are available under http://docs.python.org/devguide; if not, someone else will do it.

----------
nosy: +eric.araujo, haypo, ncoghlan, ron_adam
stage:  -> needs patch
title: pydoc.synopsis breaks if filesystem returns mtime of 0 (common for filesystems without mtime) -> pydoc.synopsis breaks if filesystem returns mtime of 0
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:38:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 21:38:03 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1311370683.28.0.737055018772.issue12575@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>From a top level view, the patch adds PyAST_Validate (with helpers) to ast.c and one call to PyAST_Validate in bltinmodule.c in builtin_compile(). The added tests do every silly thing you can think of.

Does PyAST_Validate get invoked for all calls to compile() or just those with an ast as input. To put it another way, does it validate *all* asts, including those generated by the code parser, or just user-constructed asts. If just the latter now, it seems that turning it on for parser asts at least temporarily could test that it does not invalidate valid code and could be used to test an ast-level optimizer.

Two obvious questions: 1) does this address a real problem that has happened in the field or something that just *might* happen; 2) what is the time penalty (compared to the time of compilation). I guess these amount to "Is the maintenance burden on developers and speed burden on users worth the benefit?". In theory, I am in favor of anything that prevents segfaults. Would that ctypes use could be similarly validated (yes, this is a joke;-).

A last question, whose answer might depend on those above: given that the new function is not exposed to users, why not validate as part of compilation, to avoid walking the tree twice?

----------
nosy: +terry.reedy
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:40:54 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 22 Jul 2011 21:40:54 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1311370854.26.0.312350776273.issue12575@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

1) Yes, it address a real concern that arose during Armin's GSOC project which has been developing a unified template compilation architecture (via the AST module) for Django and Jinja2.
2) Asking speed questions about this is silly IMO, if compiling functions is your bottleneck, your application design is very very broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:41:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:41:07 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1311370867.02.0.533673396783.issue12604@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Extension Modules -Library (Lib)
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12604>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:43:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Jul 2011 21:43:52 +0000
Subject: [issue10881] test_site and macframework builds fails
In-Reply-To: <1294689247.64.0.100970558273.issue10881@psf.upfronthosting.co.za>
Message-ID: <1311371032.17.0.134161707572.issue10881@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review, patch
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10881>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:44:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 21:44:00 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311371040.33.0.522128301281.issue12576@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Could we look for 'tion: Closed' instead of "Connection: Closed", to accomodate servers that garble the response, even if it is a hack?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:44:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jul 2011 21:44:07 +0000
Subject: [issue12592] modify configure.in to detect OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <E1QkNVt-0001Px-4R@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b24a2ccae56a by Charles-Fran?ois Natali in branch '2.7':
Issue #12592: Make Python build on OpenBSD 5 (and future major releases).
http://hg.python.org/cpython/rev/b24a2ccae56a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12592>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:48:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jul 2011 21:48:39 +0000
Subject: [issue12592] modify configure.in to detect OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <E1QkNaG-0001jQ-Ca@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9c7f9d5841ff by Charles-Fran?ois Natali in branch '3.2':
Issue #12592: Make Python build on OpenBSD 5 (and future major releases).
http://hg.python.org/cpython/rev/9c7f9d5841ff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12592>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:51:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Jul 2011 21:51:51 +0000
Subject: [issue12592] modify configure.in to detect OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <E1QkNdO-0001zl-J3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 63de97ae832e by Charles-Fran?ois Natali in branch 'default':
Merge - Issue #12592: Make Python build on OpenBSD 5 (and future major
http://hg.python.org/cpython/rev/63de97ae832e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12592>
_______________________________________

From report at bugs.python.org  Fri Jul 22 23:56:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Jul 2011 21:56:25 +0000
Subject: [issue12592] modify configure.in to detect OpenBSD 5.x
In-Reply-To: <1311152181.76.0.785487294924.issue12592@psf.upfronthosting.co.za>
Message-ID: <1311371785.06.0.813771944476.issue12592@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed.
R?mi, thanks for reporting this (and other OpenBSD-specific bugs :-).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12592>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:04:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 22:04:01 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311372241.12.0.0583569270457.issue12600@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

David, is this the sort of thing you mean?

@skip # so do not run without backend
class AbstractDB2Testcase:
  backend = None
  <code>

class PostgressDB2Testcase(AbstractDB2Testcase):
  backend = postgress # well, enough info to fine it

...

If so, I think we should close this.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:11:40 2011
From: report at bugs.python.org (Vlada Peric)
Date: Fri, 22 Jul 2011 22:11:40 +0000
Subject: [issue12616] zip fixer fails on zip()[:-1]
In-Reply-To: <1311372700.75.0.0919550613362.issue12616@psf.upfronthosting.co.za>
Message-ID: <1311372700.75.0.0919550613362.issue12616@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

The zip fixer fails on this code:

zip(B, D)[:-1]

I fixed this by wrapping explicitly with list(), but that creates a duplicate list on Python 2. 

(Like the other fixes I reported, I assume this also applies to 3.3, but I didn't test it so I don't know; adding Eric and Benjamin to nosy, though)

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 140919
nosy: VPeric, benjamin.peterson, eric.araujo
priority: normal
severity: normal
status: open
title: zip fixer fails on zip()[:-1]
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12616>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:17:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jul 2011 22:17:20 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1311373040.65.0.127324492252.issue12608@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/issue12608>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:17:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Jul 2011 22:17:29 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1311373049.89.0.502979456044.issue12575@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:26:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Jul 2011 22:26:03 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <20110719122224.GA40111@sherwood.local>
Message-ID: <CAH_1eM24Y0ADauNB2EJXYw32_g_QpBnC-q-CS7S5oUfY2oym5w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

>   One could argue that something had happened before the fsync(2),
>   so that code which blindly did so is too dumb to do any right
>   decision anyway.  Even PEP 3151 won't help.

I don't understand. If the syscall supposed to flush the disk's buffer
cache fails - be it fcntl() or sync_file_range() - I think the error
should be propagated, not silently ignored and replaced with another
syscall which doesn't have the same semantic. That's all.

> - I favour haypos fullsync() approach, because that could probably
>   make it into it.  Yet Python doesn't offer any possibility to
>   access NetBSD DISKSYNC stuff sofar.

Are you willing to update your patch accordingly?

> - Currently the programmer must be aware of any platform specific
>   problems.  I, for example, am not aware of Windows.  How can
>   i give any guarantee to users which (will) use my S-Postman on
>   Windows?  I need to put trust in turn into the Framework i am
>   using - Python.  And that makes me feel pretty breathless.

I agree.

> - Fortunately Python is dynamic, so that one simply can replace
>   os.fsync().  Works once only though (think signal handlers :=).

Yes, but since it's a fairly reasonable and useful feature, I think it
could be merged.

>   + Aaarrg!  I'm a liar!!  I lie about - data integrity!!!

Well, actually, some hard disks lie about this too :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:35:41 2011
From: report at bugs.python.org (rpointel)
Date: Fri, 22 Jul 2011 22:35:41 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311111401.9.0.18298571301.issue12588@psf.upfronthosting.co.za>
Message-ID: <1311374141.24.0.917737373224.issue12588@psf.upfronthosting.co.za>


rpointel <python at xiri.fr> added the comment:

Hello,

I just want to inform you that valgrind does not work on OpenBSD (only Linux and Darwin).

Thanks for your help,

Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:40:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jul 2011 22:40:49 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1311374449.67.0.718736146842.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg70327

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:41:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jul 2011 22:41:06 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1217181277.27.0.0572027678775.issue2771@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Testing authorage

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sat Jul 23 00:42:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jul 2011 22:42:34 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1311374554.07.0.910555658502.issue2771@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy:  -loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sat Jul 23 03:09:50 2011
From: report at bugs.python.org (Josh Triplett)
Date: Sat, 23 Jul 2011 01:09:50 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311383390.53.0.206919730228.issue12603@psf.upfronthosting.co.za>


Josh Triplett <josh at joshtriplett.org> added the comment:

The current behavior of pydoc will cause synopsis to always incorrectly return "None" as the synopsis for any module with mtime == 0.  Both of the proposed fixes will fix that bug without affecting any case where mtime != 0, so I don't think either one has backward-compatibility issues.

I'd suggest using the fix of changing the .get call to return a default of (None, None) and changing the conditional to "lastupdate is not None and lastupdate < mtime".  That variant seems like more obvious code (since None clearly means "no lastupdate time"), and it avoids special-casing an mtime of 0 and bypassing the synopsis cache.

I don't mind writing a patch if that would help this fix get in.  I'll try to write onein the near future, but I certainly won't mind if someone else beats me to it. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Sat Jul 23 03:16:32 2011
From: report at bugs.python.org (Kuberan Naganathan)
Date: Sat, 23 Jul 2011 01:16:32 +0000
Subject: [issue12545] Incorrect handling of return codes in the posix_lseek
	function in posixmodule.c
In-Reply-To: <CAH_1eM2eh0io5_Bi-1KP2NZn8mfq8ndE=JOinsHBb2fs-yN_RQ@mail.gmail.com>
Message-ID: <CAK=_o0g5vCEQeryEOVa91wJx-rn_2KvxNxLk9BBwizna0TcJdg@mail.gmail.com>


Kuberan Naganathan <kubiyak at gmail.com> added the comment:

yes.  i noticed problem on solaris on the /proc/<pid>/as file which usually
has mapped regions beyond 2^63 in most process files
On Jul 22, 2011 4:35 PM, "Charles-Fran??ois Natali" <report at bugs.python.org>
wrote:
>
> Charles-Fran????ois Natali <neologix at free.fr> added the comment:
>
> Patch attached.
>
>> For lseek, we can rely on errno. Try something like that:
>>
>> errno = 0;
>> offset = lseek(...);
>> if (offset == (off_t)-1 && errno) /* error */
>>
>
> It's a little bit overkill :-) (for mktime, time_t can overflow easily
> on 32-bit).
>
>> We can write a test using a sparse file... Or maybe a mmap object?
>>
>
> I'm not sure it's easily testable, because it's really a corner case
> not addressed by POSIX. On my Linux box, I can't get lseek to return a
> negative value, I get EINVAL - which does make sense (the Linux kernel
> doesn't accept or return negative file offsets, see
> http://lwn.net/Articles/138063/).
>
> Kuberan, on what operating system did you notice this problem? Solaris?
>
> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file22719/lseek_negative.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12545>
> _______________________________________

----------
Added file: http://bugs.python.org/file22721/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________
-------------- next part --------------
<p>yes.?? i noticed problem on solaris on the /proc/&lt;pid&gt;/as file which usually has mapped regions beyond 2^63 in most process files</p>
<div class="gmail_quote">On Jul 22, 2011 4:35 PM, &quot;Charles-Fran??ois Natali&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br type="attribution">&gt; <br>&gt; Charles-Fran????ois Natali &lt;<a href="mailto:neologix at free.fr">neologix at free.fr</a>&gt; added the comment:<br>
&gt; <br>&gt; Patch attached.<br>&gt; <br>&gt;&gt; For lseek, we can rely on errno. Try something like that:<br>&gt;&gt;<br>&gt;&gt; errno = 0;<br>&gt;&gt; offset = lseek(...);<br>&gt;&gt; if (offset == (off_t)-1 &amp;&amp; errno) /* error */<br>
&gt;&gt;<br>&gt; <br>&gt; It&#39;s a little bit overkill :-) (for mktime, time_t can overflow easily<br>&gt; on 32-bit).<br>&gt; <br>&gt;&gt; We can write a test using a sparse file... Or maybe a mmap object?<br>&gt;&gt;<br>
&gt; <br>&gt; I&#39;m not sure it&#39;s easily testable, because it&#39;s really a corner case<br>&gt; not addressed by POSIX. On my Linux box, I can&#39;t get lseek to return a<br>&gt; negative value, I get EINVAL - which does make sense (the Linux kernel<br>
&gt; doesn&#39;t accept or return negative file offsets, see<br>&gt; <a href="http://lwn.net/Articles/138063/">http://lwn.net/Articles/138063/</a>).<br>&gt; <br>&gt; Kuberan, on what operating system did you notice this problem? Solaris?<br>
&gt; <br>&gt; ----------<br>&gt; keywords: +patch<br>&gt; Added file: <a href="http://bugs.python.org/file22719/lseek_negative.diff">http://bugs.python.org/file22719/lseek_negative.diff</a><br>&gt; <br>&gt; _______________________________________<br>
&gt; Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&gt; &lt;<a href="http://bugs.python.org/issue12545">http://bugs.python.org/issue12545</a>&gt;<br>&gt; _______________________________________<br>
</div>

From report at bugs.python.org  Sat Jul 23 03:39:58 2011
From: report at bugs.python.org (py.user)
Date: Sat, 23 Jul 2011 01:39:58 +0000
Subject: [issue12617] Mutable Sequence Type can work not only with iterable in
	slice[i:j] = t
In-Reply-To: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>
Message-ID: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

1)
4.6.4 Mutable Sequence Types

| s[i:j] = t |  slice of s from i to j is replaced |
|            |  by the contents of the iterable t  |


>>> lst = list('abc')
>>> barr = bytearray(b'abc')
>>> lst[:1] = 4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only assign an iterable
>>> barr[:1] = 4
>>> barr
bytearray(b'\x00\x00\x00\x00bc')
>>>

there is no info about this feature in the documentation

2)
4.6.4 Mutable Sequence Types

| s.extend(x) |  same as s[len(s):len(s)] = x |

>>> lst = list('abc')
>>> barr = bytearray(b'abc')
>>> lst.extend(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> barr.extend(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> lst[len(lst):len(lst)] = 4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only assign an iterable
>>> barr[len(barr):len(barr)] = 4
>>> barr
bytearray(b'abc\x00\x00\x00\x00')
>>>

barr.extend(x)  !=  barr[len(barr):len(barr)] = x

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 140924
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: Mutable Sequence Type can work not only with iterable in slice[i:j] = t
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12617>
_______________________________________

From report at bugs.python.org  Sat Jul 23 03:56:22 2011
From: report at bugs.python.org (higery)
Date: Sat, 23 Jul 2011 01:56:22 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311386182.2.0.735684394793.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>IOError: [Errno 13] Permission denied: '/tmp/user/1013/tmp2xp9qc/tmpwhzzmg/script1'

I have added an 'ensure_directory()' function to build_script.py, but I'm not sure if it can fix this error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jul 23 03:58:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Jul 2011 01:58:57 +0000
Subject: [issue12617] Mutable Sequence Type can work not only with iterable in
	slice[i:j] = t
In-Reply-To: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>
Message-ID: <1311386337.76.0.749372838055.issue12617@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/issue12617>
_______________________________________

From report at bugs.python.org  Sat Jul 23 04:50:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Jul 2011 02:50:56 +0000
Subject: [issue12617] Mutable Sequence Type can work not only with iterable in
	slice[i:j] = t
In-Reply-To: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>
Message-ID: <1311389456.78.0.584021670451.issue12617@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

To my eye, this looks like a bytearray API bug in the bytearray implementation.  ISTM, the rhs of a slice assignment needs to be restricted to iterable inputs.

I'm marking this as low priority because the documented behaviors (i.e. normal slice assignment from an iterable) appear to be working fine.  So, there is no rush to take away the gratuitous API extension that accepts an integer input where a slice is usually expected.  The extension is not entirely harmless though -- we do lose the error-checking for the common mistake of writing s[i:j]=x instead of s[i:j]=[x].

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12617>
_______________________________________

From report at bugs.python.org  Sat Jul 23 04:52:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Jul 2011 02:52:12 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1311389532.81.0.699032722272.issue12613@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12613>
_______________________________________

From report at bugs.python.org  Sat Jul 23 06:03:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Jul 2011 04:03:01 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311393781.12.0.583893295874.issue12600@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, except that it would be:

   class PostgressDB2Testcase(AbstractDB2Testcase, unittest.TestCasse):

The fact that other test frameworks have found it worth implementing indicates there *might* be something worthwhile there, but unless someone makes the case, yes we should close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Sat Jul 23 07:28:47 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 05:28:47 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1311398927.87.0.520548319164.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Alright, since *some* tests are better than no tests at all, I will try to combine the patches currently attached to the issue, port them to the Hg repo and commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 23 07:47:40 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 05:47:40 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1311400060.11.0.533131855752.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Brett, what do you mean by "listed as an essential test in regrtest". The regrtest.STDTESTS list?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 23 07:51:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 05:51:41 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <E1QkV7i-0002pB-6l@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset be558ad15789 by Eli Bendersky in branch 'default':
Issue #11049: adding some tests to test.support
http://hg.python.org/cpython/rev/be558ad15789

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 23 07:53:34 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 05:53:34 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1311400414.57.0.184188229126.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

This changeset incorporates Giampaolo's patch with a minor fix in `test.support.python_is_optimized` (which returned '' for False sometimes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:11:38 2011
From: report at bugs.python.org (Austin Bingham)
Date: Sat, 23 Jul 2011 06:11:38 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311372241.12.0.0583569270457.issue12600@psf.upfronthosting.co.za>
Message-ID: <CAEZidR1x_z86H=PQ0e4vfgxekULQ0ijJy3QnGkfYAx4y1OJv0Q@mail.gmail.com>


Austin Bingham <austin.bingham at gmail.com> added the comment:

Yes, in some sense that's what I'm thinking of. But one problem with
this straightforward approach is that it doesn't scale well. If I've
got many TestCases, each if which I want to parameterize, I have to
create subclasses for each parameterization. If I add a new
parameterization, of course I have to add new subclasses for each.
Even worse, if my parameterizations are dynamically generated (e.g. if
my parameterizations are based on installed plugins or something),
then this naive approach just breaks down.

There are, as has been mentioned, various ways to implement quite
sophisticated parameterized test cases purely by subclassing the
existing loaders, runner, and TestCase functionality. On the other
hand (and recognizing that I may well be missing something), it's not
particularly straightforward to do so, and it feels like a bit more of
a hack than I would like. There are a lot of moving parts in unittest,
and when I have to start fiddling with one to get special new behavior
I always worry that I might subtly break something else...but maybe
I'm just being neurotic ;)

So, I'll put forward two arguments for official support for
parameterized test cases. The first is what I mentioned above:
implementing it extrinsic to the existing system seems non-obvious and
complex, and thus error prone. Putting official support in unittest
would mean nobody else ever had to worry about it. On the other hand,
assuming that parameterized test cases can be fully and cleanly
implemented without touching unittest, this also argues that someone
should just create an external package to do so, and leave unittest
alone.

The second argument is symmetry. If you implement parameterization of
individual tests, it seems like the logic for justifying them really
could be generalized for collections of tests, both "cases" and
"suites". I admit that this is just a gut feeling, but there you go.

Ultimately, I'm less concerned that any changes are made to unittest
than I am that the issue is given due consideration. Heck, a proper
"fix" might be to just add a section to the docs describing how one
might implement parameterized testcases.

On Sat, Jul 23, 2011 at 12:04 AM, Terry J. Reedy <report at bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> David, is this the sort of thing you mean?
>
> @skip # so do not run without backend
> class AbstractDB2Testcase:
> ?backend = None
> ?<code>
>
> class PostgressDB2Testcase(AbstractDB2Testcase):
> ?backend = postgress # well, enough info to fine it
>
> ...
>
> If so, I think we should close this.
>
> ----------
> nosy: +terry.reedy
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12600>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:19:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 06:19:54 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311401994.0.0.786014869823.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

OK, I can reproduce the problem on a clean virtual machine running a pristine XP home SP2. No Python was previously installed.

Steps to reproduce:

1. Install Python 3.2.1 MSI from http://www.python.org/download/releases/3.2.1/
2. Run IDLE from start menu
3. Close IDLE
4. A pythonw.exe process stays running after IDLE has exited

Running steps 2-3 N times leaves N pythonw.exe processes alive

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:26:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Jul 2011 06:26:22 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1311402382.88.0.734064136354.issue11049@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Several buildbot are failing after the commit:

======================================================================
FAIL: test_get_original_stdout (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_support.py", line 34, in test_get_original_stdout
    self.assertEqual(support.get_original_stdout(), sys.stdout)
AssertionError: <_io.TextIOWrapper name=1 mode='w' encoding='ANSI_X3.4-1968'> != <_io.StringIO object at 0xb715b46c>

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:27:43 2011
From: report at bugs.python.org (angus)
Date: Sat, 23 Jul 2011 06:27:43 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311402463.09.0.853855611642.issue12576@psf.upfronthosting.co.za>


angus <angus at amcinnes.info> added the comment:

I'm experiencing a related problem:
---
from urllib.request import urlopen
print(urlopen('https://mtgox.com/').read())
---
prints b'' rather than the page content.

It looks like mtgox.com always sends 'Connection: Keep-Alive'. So some hack like recognising 'tion: close' wouldn't fix it.

----------
nosy: +angus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:33:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 23 Jul 2011 06:33:04 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311402784.6.0.819926558441.issue12576@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:33:07 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 23 Jul 2011 06:33:07 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1311402463.09.0.853855611642.issue12576@psf.upfronthosting.co.za>
Message-ID: <20110723063250.GA2658@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I am against hacks like tion: close. Under worst case, we shall revert
the change which caused this regression in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:43:35 2011
From: report at bugs.python.org (Robert Xiao)
Date: Sat, 23 Jul 2011 06:43:35 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311403415.49.0.882199048136.issue12576@psf.upfronthosting.co.za>


Robert Xiao <nneonneo at gmail.com> added the comment:

S3 also doesn't send any kind of connection header at all.

x-amz-id-2: WWuo30Fk2inKVcC5dH4GOjvHxnqMa5Q2+AduPm2bMhL1h3GqzOR0EPwUv0biqv2V
x-amz-request-id: 3CCF6B6A000E6446
Date: Sat, 23 Jul 2011 06:42:45 GMT
x-amz-meta-s3fox-filesize: 27692
x-amz-meta-s3fox-modifiedtime: 1213292340000
Last-Modified: Thu, 12 Jun 2008 17:45:12 GMT
ETag: "c4db184c97f1d6b0b6e7ee17a73e785b"
Accept-Ranges: bytes
Content-Type: application/pdf
Content-Length: 27692
Server: AmazonS3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sat Jul 23 08:45:06 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 06:45:06 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311403506.59.0.0480273416332.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Am I missing something, or is there no explicit command to kill the subprocess on Windows in PyShell.py

The kill_subprocess method (which does get invoked) of ModifiedInterpreter is:

    def kill_subprocess(self):
        try:
            self.rpcclt.close()
        except AttributeError:  # no socket
            pass
        self.unix_terminate()
        self.tkconsole.executing = False
        self.rpcclt = None

The subprocess is started with:

    self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args)

Could it be that in earlier versions this ensured the subprocess exited with its parent, but this somehow got modified?

Note that the same code existed in PyShell.py for ages, so it's unlikely that the culprit is there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 09:14:25 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Jul 2011 07:14:25 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1311405265.94.0.537361133684.issue12326@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I give up. Call it 'linux3', then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul 23 09:42:51 2011
From: report at bugs.python.org (Sjoerd de Vries)
Date: Sat, 23 Jul 2011 07:42:51 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>


New submission from Sjoerd de Vries <sjdv1982 at gmail.com>:

When you specify cfile to be in the current directory, an error occurs (line 133).
I have fixed the file, see attached

----------
components: Library (Lib)
files: py_compile.py
messages: 140940
nosy: sjdv1982
priority: normal
severity: normal
status: open
title: py_compile cannot create files in current directory
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22722/py_compile.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 09:46:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 07:46:23 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311407183.65.0.484168988477.issue12618@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Please create a patch in unified format.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 09:52:58 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 07:52:58 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1311407578.29.0.747448803578.issue11435@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Done (in rev e32f140a020b).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Sat Jul 23 09:54:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 07:54:25 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1311407665.38.0.622574539802.issue11975@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

index does create targets, but they are not accessible for creating a link *to* it. They are only used for links from the indices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Sat Jul 23 10:15:42 2011
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 23 Jul 2011 08:15:42 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1311408942.1.0.734940543759.issue12326@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

this does sound very ugly.

so we get now another mostly unmaintained platform directory? unfortunately the generated header files are almost never updated during a releaes cycle.

and we repeat the mistakes that some constants differ on some architectures?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul 23 10:17:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 08:17:20 +0000
Subject: [issue12605] Enhancements to gdb 7 debugging hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1311409040.02.0.190396649633.issue12605@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +georg.brandl, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12605>
_______________________________________

From report at bugs.python.org  Sat Jul 23 10:18:17 2011
From: report at bugs.python.org (Sjoerd de Vries)
Date: Sat, 23 Jul 2011 08:18:17 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311409097.34.0.168478945185.issue12618@psf.upfronthosting.co.za>


Sjoerd de Vries <sjdv1982 at gmail.com> added the comment:

The attached file just works.
You can diff with trunk, or wherever python devs store the latest version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 10:21:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 08:21:39 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311409299.09.0.323863334016.issue12618@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It might work right now, but in case the file changes before your change can be processed, we will lose the previous changes if we just copy in your new file.

IOW, you're making our work much harder and your change is less likely to be applied.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 10:24:48 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 08:24:48 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311409488.2.0.58050976995.issue12576@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Recognizing "ction: close" as "Connection: close" is exactly what those servers do *not* want you to do.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Sat Jul 23 10:27:43 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 23 Jul 2011 08:27:43 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311409663.7.0.875190314194.issue12540@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Doesn't unix_terminate() also get called on Windows?  If so, what does os.kill() do on Windows?  The docs for os.kill say "New in version 3.2: Windows support."  Perhaps this was being skipped before and now has some negative effect?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:22:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Jul 2011 09:22:40 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1311408942.1.0.734940543759.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E2A92DA.4040701@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's too late to "fix" sys.platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:37:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Jul 2011 09:37:27 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1311413847.73.0.341656012806.issue12581@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Peter?s patch now uses iter(thing) instead of len(thing) to assess sequenciness.  I made this comment:
> You can iterate over an iterator (which is not a sequence). Here I
> don?t know if the code talks about sequence because it pre-dates
> iterators or because it really wants sequences.

Peter?s reply:
> Fair point. The *code*, though, doesn't say either, and len() doesn't
> express it any better (IMO) than iter(). It seems to me that the
> check basically just verifies that the presumed sequence can be 
> safely iterated over, before trying to enter the for loop. If so, my
> iter() check seems to encapsulate it cleanly in code rather than
> needing an additional comment.

I think iter may exhaust a non-repeatable iterable, whereas len would give a TypeError and not consume the iterable.  iter(thing) being successful does not guarantee that a second iteration will succeed.

I?ve had a look at the docstring and the reST docs, and they clearly say that sequences are supported, not arbitrary iterables.

> If not -- if the code should enforce "true sequence-ness" -- maybe it
> should use the ABC (as my first patch did)? Which is *correct*,
> though, I'm too much an outsider to judge!

Note that ABCs are not strict, ?true? type checks like there is in other languages :)

> (I tried to check the revlog for clues, but the code entered in
> 5a416a6417d3, which was the new urllib package combining several old
> packages. It's been there for a while.)

Log viewing tools usually let you follow the history across renames, or otherwise let you see the history for a file that?s not anymore in the tip revision.  Here it was Lib/urlparse.py.  (Just saying this for your information, it does not matter anymore to check the history to find if the code pre-dates iterators.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:40:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Jul 2011 09:40:36 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311414036.5.0.993654123567.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Same bug.  I?ve added debug prints to find out the rights (UNIX permission system) of the files, and they?re very strange: --wxrw--wt (the read bit is missing, and the t is strange).  It should be -rwxr-xr-x, like other programs.

The bug is likely this change:
-                os.chmod(target, 0755)
+                os.chmod(target, 755)

An octal literal in 3.x is 0o755.  Decimal 755 means 0o1363, which is not good :)

I?ll let you check the Python docs and Wikipedia if you don?t know these rxw or octal codes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:43:33 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 09:43:33 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

I suggest that platform-specific modules be automatically regenerated during installation. I'm attaching a patch.

----------
files: python-regenerate_platdir.patch
keywords: patch
messages: 140952
nosy: Arfrever, amaury.forgeotdarc, djc, doko, eric.araujo, ezio.melotti, haypo, jwilk, lemburg, loewis, maniram.maniram, neologix, petri.lehtinen, pitrou, python-dev, r.david.murray, rosslagerwall
priority: normal
severity: normal
status: open
title: Automatically regenerate platform-specific modules
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22723/python-regenerate_platdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:43:46 2011
From: report at bugs.python.org (Sjoerd de Vries)
Date: Sat, 23 Jul 2011 09:43:46 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311414226.98.0.106142739981.issue12618@psf.upfronthosting.co.za>


Sjoerd de Vries <sjdv1982 at gmail.com> added the comment:

Makes no sense to me: since I don't have the trunk version, I can only diff -c against 3.2 release. Doing a diff against trunk is 1 sec of work for you.

But I am just being a helpful user; so if a diff is what you want, here it is. No trouble for me, since I am on Linux. 

Not a very nice policy to any helpful Windows users, though: they won't have diff installed and they would waste an hour or so on this.

----------
keywords: +patch
Added file: http://bugs.python.org/file22724/py_compile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:44:18 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 09:44:18 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311414258.37.0.813889316514.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Indeed, unix_terminate is invoked on Windows, and since Windows now has "os.kill" it runs. However, it appears that the actual os.kill call throws OSError, saying:

    [Error 87] The parameter is incorrect

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:45:08 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 09:45:08 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1311414308.73.0.452264570061.issue12326@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

See issue #12619 for potential solution for platform-specific modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:45:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Jul 2011 09:45:31 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311414331.45.0.371042586354.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I confirm fixing 0o755 makes the tests pass for me.

Your code gives one warning:
build_scripts.py:241: BytesWarning: str() on a bytes instance
  hdr = "#!%(executable)s%(options)s\n" % locals()

The object with the name executable or options is bytes, which you should explicitly convert to a string with decode.  I also don?t like using locals(), but that?s a personal style thing.

Your test should catch stdout (see other packaging tests for how to do that), so that people or buildbots running the tests don?t see ?Hello world!?, and so that you can run asserts for the output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:47:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Jul 2011 09:47:07 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311414427.37.0.0658835582266.issue12619@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Autotools/make newbie here) Why during install and not build?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:49:49 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 09:49:49 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311414589.85.0.790003622859.issue12619@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I don't care when they will be regenerated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Sat Jul 23 11:54:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 09:54:16 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311414856.97.0.718968791577.issue12618@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

It's a context patch, not a unified patch, and it is reversed :) .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:07:40 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 23 Jul 2011 10:07:40 +0000
Subject: [issue12617] Mutable Sequence Type can work not only with iterable in
	slice[i:j] = t
In-Reply-To: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>
Message-ID: <1311415660.43.0.0263961292451.issue12617@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/issue12617>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:17:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Jul 2011 10:17:24 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1311416244.52.0.107184475744.issue12604@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Should the component really be extension modules? I don't believe _sre.c is a part of the API, and the problem is embedding Python as a whole.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12604>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:19:54 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 23 Jul 2011 10:19:54 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1311413847.73.0.341656012806.issue12581@psf.upfronthosting.co.za>
Message-ID: <20110723101939.GA2464@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Sat, Jul 23, 2011 at 09:37:27AM +0000, ?ric Araujo wrote:
> I?ve had a look at the docstring and the reST docs, and they clearly
> say that sequences are supported, not arbitrary iterables.

Yeah. At the first cut, when I saw the suggestion of iter(), I thought
it was better, but looking at it again, we just need to test the
sequence-ness. I would leave it as such with len() unless we come up
with a case that it does not test the sequenceness completely.

As Eric points out, changing it to iter may cause some side-effects
(of exhaustion of the container)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:33:35 2011
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 23 Jul 2011 10:33:35 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311417215.83.0.512440511205.issue12619@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

is auto-generation wanted?
are you sure that you can't end up with bad syntax?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:43:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 10:43:11 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <E1QkZfp-000463-5x@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e171db785c37 by Senthil Kumaran in branch '3.2':
Fix closes issue12581 - Increase the urllib.parse test coverage. Patch by Petter Haggholm.
http://hg.python.org/cpython/rev/e171db785c37

New changeset fcccda3c546f by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes issue12581 - Increase the urllib.parse test coverage. Patch by Petter Haggholm.
http://hg.python.org/cpython/rev/fcccda3c546f

New changeset ed79da800b4a by Senthil Kumaran in branch '2.7':
merge from 3.2 - Fix closes issue12581 - Increase the urllib.parse test coverage (cases applicable to 2.7). Patch by Petter Haggholm.
http://hg.python.org/cpython/rev/ed79da800b4a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:43:13 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 10:43:13 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311417793.16.0.45818808212.issue12618@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, we can work with this patch.  Thanks.

Yes, we can diff against 3.2, but for that you would have at least needed to specify

* that you worked on a released version
* and that that version is 3.2

Otherwise, we cannot know what to diff against.

Note that even Windows users usually use Python from Mercurial for developing, so that they can use "hg diff" to create a patch easily.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:45:02 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 10:45:02 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311417902.3.0.067029048045.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Here's a simple reproducer for the same problem, without the context of IDLE. As far as I understand, what IDLE's spawn and then kill process are doing is:

  import os
  from signal import SIGTERM

  pid = os.spawnv(os.P_NOWAIT, "notepad.exe", ['notepad.exe'])
  print('pid = %s, SIGTERM = %s' % (pid, SIGTERM))
  os.kill(pid, SIGTERM)

Running this, the notepad.exe subprocess stays alive after the script exits, and I get the error:

  pid = 1868, SIGTERM = 15
  Traceback (most recent call last):
    File "k.py", line 6, in <module>
      os.kill(pid, SIGTERM)
  WindowsError: [Error 87] The parameter is incorrect

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:45:37 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 10:45:37 +0000
Subject: [issue12617] Mutable Sequence Type can work not only with iterable in
	slice[i:j] = t
In-Reply-To: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>
Message-ID: <1311417937.43.0.327117679652.issue12617@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, this is a bug in bytearray and should be fixed.

----------
assignee: docs at python -> 
components:  -Documentation
nosy: +georg.brandl
versions: +Python 2.7, Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12617>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:46:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 23 Jul 2011 10:46:55 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <E1QkZfp-000463-5x@dinsdale.python.org>
Message-ID: <20110723104639.GB2464@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks a lot for the patch, Petter Haggholm.

I was initially hesitant to have separate tests for functions/methods
which are helper functions and not necessarily have documented api.
My thought was that those should be tested as part of the public api.

But once I tried coverage report on the module and saw that
unexercised parts, I thought your current patch does indeed a lot of
value. Aiming for a 100% test coverage of module is always a joy!. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:47:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 10:47:03 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311418023.56.0.676142611816.issue12540@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, the docs say "Any other value for sig will cause the process to be unconditionally killed by the TerminateProcess API [...]"

What happens if you try to use other signals (like signal.SIGKILL) instead of SIGTERM?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 12:49:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 10:49:39 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311418179.29.0.58809267076.issue12540@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The other question is if it is an access control problem.

win32_kill tries to open the process with PROCESS_ALL_ACCESS, while IMO PROCESS_TERMINATE would suffice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 13:05:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 11:05:45 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311419145.41.0.549751145822.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg, I'm now debugging into win32_kill, and it's an error in OpenProcess, so this *could* be a security issue.

The process is started with _spawnv, so maybe this causes problems opening it with OpenProcess later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 13:08:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 11:08:23 +0000
Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly
	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1311419303.58.0.0655497687486.issue8714@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This behavior was introduced (exposed by?) r68460.

After a quick look, I don't see anything wrong with r68460, but it might very well have exposed this problem which was lurking before.

> When Python is compiled without threads, the behavior is normal.

We've already had some problems - especially on *BSD - when mixing signals and threads (and it might be even worse on OpenBSD, since pthreads are implemented in user-space). However, IIUC, in this case you only have a single thread, right?

Could you post the output of an strace (well, ktrace on OpenBSD)?
Is Python compiled with readline support?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8714>
_______________________________________

From report at bugs.python.org  Sat Jul 23 13:14:10 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 11:14:10 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311419650.01.0.897345171927.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

According to http://msdn.microsoft.com/en-us/library/7zt1y878%28v=vs.80%29.aspx, on Windows _spawnv in async mode (P_NOWAIT) returns the process _handle_, not the process ID.

win32_kill uses OpenProcess, passing it pid to obtain the handle, but this pid is already the process handle. 

Removing the whole call to OpenProcess in win32_kill and passing pid (instead of handle) directly to TerminateProcess, solves the problem.

----

So this appears to be a mismatch between os.spawnv and os.kill on windows. The fist returns the process handle, the second expects a process ID.

Note that the documentation of os.spawnv mentions something about this:

  If mode is P_NOWAIT, this function returns the process id of the new process; [...] On Windows, the process id will actually be the process handle, so can be used with the waitpid() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 13:21:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jul 2011 11:21:27 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311420087.11.0.00103335883756.issue12540@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, on the other hand there may be valid use cases for using os.kill() with a PID.  Argh.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 13:21:46 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 11:21:46 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311420106.03.0.660712308701.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I don't think there's a problem with os.spawnv and os.kill - they do what their docs describe.

IMHO, the solution should be to change IDLE so that it uses subprocess.Popen for both starting and killing the child process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 13:27:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 11:27:35 +0000
Subject: [issue12620] pending calls: make `pendingbusy` flag static to
	Py_MakePendingCalls()
In-Reply-To: <1311420455.91.0.738600142656.issue12620@psf.upfronthosting.co.za>
Message-ID: <1311420455.91.0.738600142656.issue12620@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Trivial patch.
In Python/ceval.c, when compiled with threads, make the `pendingbusy` flag used to guard against reentrant calls static to Py_MakePendingCalls().
Also, make it an int and rename it to `busy` to be consistent with the non-threaded code (int might also be a bit faster).

----------
components: Interpreter Core
files: pending_busy.diff
keywords: needs review, patch
messages: 140976
nosy: neologix, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: pending calls: make `pendingbusy` flag static to Py_MakePendingCalls()
versions: Python 3.3
Added file: http://bugs.python.org/file22725/pending_busy.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12620>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:01:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 12:01:06 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <E1Qkat9-0008RN-Tc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0018a28583f4 by Eli Bendersky in branch 'default':
Issue #11049: skip a test that fails on some buildbots
http://hg.python.org/cpython/rev/0018a28583f4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:05:40 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Jul 2011 12:05:40 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1311422740.72.0.786303453627.issue12608@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
dependencies: +add a AST validator

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12608>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:17:03 2011
From: report at bugs.python.org (higery)
Date: Sat, 23 Jul 2011 12:17:03 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311423423.41.0.267826351204.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>An octal literal in 3.x is 0o755.  Decimal 755 means 0o1363, which is not good :)

Thank you for your reminding. The reason I made this mistake is that I'm not familiar with the right way to set permission code in Python3+ .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:18:56 2011
From: report at bugs.python.org (higery)
Date: Sat, 23 Jul 2011 12:18:56 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311423536.67.0.0554403502261.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>The object with the name executable or options is bytes, which you should explicitly convert to a string with decode.  I also don?t like using locals(), but that?s a personal style thing.

Thanks for your test, I'll amend it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:22:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Jul 2011 12:22:38 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1311423758.61.0.444773870688.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

OK, the bots are green again after the last push.

Sorry about that, folks. I tested this on two different machines (Ubuntu & Win XP) before pushing the original commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:26:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 12:26:13 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <E1QkbHW-00022o-3f@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c741ba9e37ef by Nadeem Vawda in branch '3.2':
Issue #10883: Fix socket leaks in urllib.request.
http://hg.python.org/cpython/rev/c741ba9e37ef

New changeset d68765bd6490 by Nadeem Vawda in branch 'default':
Merge: #10883: Fix socket leaks in urllib.request.
http://hg.python.org/cpython/rev/d68765bd6490

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:36:39 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 23 Jul 2011 12:36:39 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <CAH_1eM24Y0ADauNB2EJXYw32_g_QpBnC-q-CS7S5oUfY2oym5w@mail.gmail.com>
Message-ID: <20110723123629.GA15527@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> > Even PEP 3151 won't help.
> 
> I don't understand. If the syscall supposed to flush the disk's buffer
> cache fails - be it fcntl() or sync_file_range() - I think the error
> should be propagated, not silently ignored and replaced with another
> syscall which doesn't have the same semantic. That's all.

I'm with you theoretically - of course errors should be propagated
to users so that they can act accordingly.
And this is exactly what the patches do, *unless* it is an error
which is not produced by the native fsync(2) call:

-- >8 --
?0%0[steffen at sherwood tmp]$ cat t.c 
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
int main(void) {
	int r  = fcntl(2, F_FULLFSYNC);
	fprintf(stderr, "1. %d: %d, %s\n", r, errno, strerror(errno));
    errno = 0;
	r = fsync(2);
	fprintf(stderr, "2. %d: %d, %s\n", r, errno, strerror(errno));
    return 0;
}
?0%0[steffen at sherwood tmp]$ gcc -o t t.c && ./t
1. -1: 25, Inappropriate ioctl for device
2. 0: 0, Unknown error: 0
?0%0[steffen at sherwood tmp]$ grep -F 25 /usr/include/sys/errno.h 
#define ENOTTY      25      /* Inappropriate ioctl for device */
-- >8 --

So in fact the patches do what is necessary to make the changed
version act just as the plain systemcall.

> > - I favour haypos fullsync() approach
> Are you willing to update your patch accordingly?

Both patches still apply onto the tip of friday noon:
http://bugs.python.org/file22016/11877.9.diff,
http://bugs.python.org/file22046/11877-standalone.1.diff.

Again: i personally would favour os.fsync(fd, fullsync=True), because
that is the only way to put reliability onto unaware facilities
unaware (e.g. my S-Postman replaces os.fsync() with a special function
so that reliability is injected in- and onto Python's mailbox.py,
which calls plain os.fsync()), but i've been convinced that this is
impossible to do.  It seems to be impossible to change os.fsync()
at all, because it has a standartized function prototype.

So what do you mean?  Shall i rewrite 11877-standalone.1.diff to
always offer fullsync() whenever there is fsync()?  This sounds to
be a useful change, because testing hasattr() of the one would
imply availability of the other.

> >   + Aaarrg!  I'm a liar!!  I lie about - data integrity!!!
> Well, actually, some hard disks lie about this too :-)

Yeah.  But hey:
"I feel save in New York City.  I feel save in New York City."
Nice weekend - and may the juice be with you!

--Steffen
Ciao, sdaoden(*)(gmail.com)
ASCII ribbon campaign           ( ) More nuclear fission plants
  against HTML e-mail            X    can serve more coloured
    and proprietary attachments / \     and sounding animations

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:45:59 2011
From: report at bugs.python.org (higery)
Date: Sat, 23 Jul 2011 12:45:59 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311425159.87.0.121953041429.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>Your test should catch stdout (see other packaging tests for how to do that), so that people or buildbots running the tests don?t see ?Hello world!?, and so that you can run asserts for the output.


Thanks. Got it - captured_stdout

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:56:01 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 12:56:01 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311425761.04.0.613565900766.issue12619@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The new patch creates platform-specific modules at build time and verifies their syntax.

----------
Added file: http://bugs.python.org/file22726/python-regenerate_platdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Sat Jul 23 14:56:18 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Jul 2011 12:56:18 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311425778.31.0.917131037933.issue12619@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Removed file: http://bugs.python.org/file22723/python-regenerate_platdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Sat Jul 23 15:35:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 13:35:09 +0000
Subject: [issue12326] Linux 3: tests should avoid using sys.platform ==
	'linux2'
In-Reply-To: <1311408942.1.0.734940543759.issue12326@psf.upfronthosting.co.za>
Message-ID: <1311428026.3001.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> this does sound very ugly.
> 
> so we get now another mostly unmaintained platform directory?
> unfortunately the generated header files are almost never updated
> during a releaes cycle.

I would be +1 to deprecate this stuff, but that's quite separate from
the issue of not breaking on Linux 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Jul 23 15:38:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 13:38:56 +0000
Subject: [issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)
In-Reply-To: <1311374141.24.0.917737373224.issue12588@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3CP-8WYqAMWEh6d-pF8sCyRLdTU=rw1Wx-O0qWV2EtTA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

and Darwin).

It would have been useful...

"""
interp 0x0, thread state 0x81855380:
Program received signal SIGSEGV, Segmentation fault.
"""

Here, the interpreter state is NULL, and this shouldn't happen.
It could be a bug linked to thread-local storage (like issue #10517):
it's just a wild guess, but if for some reason the TLS key isn't reset
before the second pass (by _PyGILState_Init()), the current tstate
after PyGILState_Ensure() could be the first pass' - stale - tstate,
with a potentially NULL interp.
Could you try building Python with --with-pydebug and re-test?

But given the stack trace, it looks more like a stack
corruption/compiler problem.

If you're motivated, you could try setting a watchpoint on the current
tstate's interpreter:

"""
cf at neobox:~/cpython$ gdb Modules/_testembed
[...]
(gdb) watch ((PyThreadState*)_PyThreadState_Current)->interp
Watchpoint 1: ((PyThreadState*)_PyThreadState_Current)->interp
"""

and see when it gets assigned NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12588>
_______________________________________

From report at bugs.python.org  Sat Jul 23 16:02:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 14:02:02 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <E1QkcmH-0002PK-MT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dbf1e1a27427 by Nadeem Vawda in branch '2.7':
Issue #10883: Fix socket leaks in urllib.request.
http://hg.python.org/cpython/rev/dbf1e1a27427

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Sat Jul 23 16:09:17 2011
From: report at bugs.python.org (higery)
Date: Sat, 23 Jul 2011 14:09:17 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311430157.68.0.310726232912.issue12394@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file22727/c5692393c621.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sat Jul 23 16:53:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Jul 2011 14:53:41 +0000
Subject: [issue12581] Increased test coverage of test_urlparse
In-Reply-To: <1310967989.12.0.947671103278.issue12581@psf.upfronthosting.co.za>
Message-ID: <1311432821.42.0.621093533947.issue12581@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Exhaustion of the iterator is easily solved by simply retaining a reference to it and iterating that (which is what I had in mind).  However, I had not thought about the problem of an *in*exhaustable iterator, and to cover that case len is indeed better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12581>
_______________________________________

From report at bugs.python.org  Sat Jul 23 17:24:38 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sat, 23 Jul 2011 15:24:38 +0000
Subject: [issue12528] Implement configurable bitfield allocation strategy
In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za>
Message-ID: <1311434678.7.0.293392799049.issue12528@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Updated patch to reflect review feedback. Allocation strategy is now specified as string in Python code.

I kept asserts in CanContinueField/CanExpandField because, as I said, default case should never be hit. Input is validated in stgdict and this should make it clear to whoever reads the code that something is very wrong if execution gets to default case.

----------
Added file: http://bugs.python.org/file22728/configurable_bitfield_allocation_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12528>
_______________________________________

From report at bugs.python.org  Sat Jul 23 17:26:28 2011
From: report at bugs.python.org (Sjoerd de Vries)
Date: Sat, 23 Jul 2011 15:26:28 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311434788.31.0.353932361864.issue12618@psf.upfronthosting.co.za>


Sjoerd de Vries <sjdv1982 at gmail.com> added the comment:

Good to hear that the patch is helpful.

Again, I am just trying to be a helpful user, making a (very very little) contribution to make Python better. I am not a Python dev at all: Python is already awesome enough for me, no desire to change it :-) 
I just want to say that a "we only accept patches" policy is not being very nice to similar helpful users on Windows, who don't have diff or Mercurial but who did manage to fix a file themselves. 

I did indicate "Python 3.2" in the bug report, maybe something went wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Sat Jul 23 17:39:08 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Jul 2011 15:39:08 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1311435548.89.0.230192944389.issue12560@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Unassigning: I tested on OpenBSD 4.5 and get other (probably unrelated
errors).

----------
assignee: skrah -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Sat Jul 23 17:49:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 15:49:57 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1311436197.79.0.341161316151.issue12560@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Sat Jul 23 17:51:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 15:51:36 +0000
Subject: [issue12620] pending calls: make `pendingbusy` flag static to
	Py_MakePendingCalls()
In-Reply-To: <1311420455.91.0.738600142656.issue12620@psf.upfronthosting.co.za>
Message-ID: <1311436296.55.0.602612256447.issue12620@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks obviously fine :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12620>
_______________________________________

From report at bugs.python.org  Sat Jul 23 17:59:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 15:59:58 +0000
Subject: [issue12605] Enhancements to gdb 7 debugging hooks
In-Reply-To: <1311282134.06.0.337847665651.issue12605@psf.upfronthosting.co.za>
Message-ID: <1311436798.52.0.368662556709.issue12605@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The improvements are welcome, but I'm not sure they're ok for 3.2 or 2.7, since they're technically a new feature.
OTOH, one could argue that better debuggability trumps the no-feature rule.

----------
nosy: +pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12605>
_______________________________________

From report at bugs.python.org  Sat Jul 23 18:02:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 16:02:19 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311436939.3.0.310748913321.issue12603@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Sat Jul 23 18:15:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 16:15:58 +0000
Subject: [issue12620] pending calls: make `pendingbusy` flag static to
	Py_MakePendingCalls()
In-Reply-To: <1311420455.91.0.738600142656.issue12620@psf.upfronthosting.co.za>
Message-ID: <E1Qkert-0003DP-4b@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cda93720c06d by Charles-Fran?ois Natali in branch 'default':
Issue 12620: Make pendingbusy flag static to Py_MakePendingCalls().
http://hg.python.org/cpython/rev/cda93720c06d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12620>
_______________________________________

From report at bugs.python.org  Sat Jul 23 18:19:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 16:19:06 +0000
Subject: [issue12620] pending calls: make `pendingbusy` flag static to
	Py_MakePendingCalls()
In-Reply-To: <1311420455.91.0.738600142656.issue12620@psf.upfronthosting.co.za>
Message-ID: <1311437946.79.0.276968093081.issue12620@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12620>
_______________________________________

From report at bugs.python.org  Sat Jul 23 18:34:48 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 23 Jul 2011 16:34:48 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1311438888.8.0.514183850305.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Here is a new version of the patch, addressing points raised in the review of the previous version.

----------
Added file: http://bugs.python.org/file22729/abc_descriptor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jul 23 18:49:28 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 23 Jul 2011 16:49:28 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1311439768.75.0.436863015939.issue11610@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy:  -michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat Jul 23 19:00:07 2011
From: report at bugs.python.org (aaugustin)
Date: Sat, 23 Jul 2011 17:00:07 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1311440407.39.0.359254621931.issue11553@psf.upfronthosting.co.za>


aaugustin <aymeric.augustin at polyconseil.fr> added the comment:

I noticed an inconsistency in the docs, and I think it falls in the "Language Reference" section of this ticket. In the definition of the import statement, after:

        | "from" module "import" "*"

we should add:

        | "from" relative_module "import" "*"


It is also possible to replace this line by:

        | "from" (module | relative_module) "import" "*"

----------
nosy: +aaugustin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Sat Jul 23 19:21:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 17:21:37 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311441697.21.0.800776453563.issue12603@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Demo:

"""
cf at neobox:~/cpython$ ./python -c "import pydoc; print(pydoc.synopsis('Lib/os.py'))"
OS routines for Mac, NT, or Posix depending on what system we're on.
[51835 refs]
cf at neobox:~/cpython$ touch -t 197001010000 Lib/os.py 
cf at neobox:~/cpython$ ./python -c "import pydoc; print(pydoc.synopsis('Lib/os.py'))"
None
[51833 refs]
"""

> I'd suggest using the fix of changing the .get call to return a default of (None,
> None) and changing the conditional to "lastupdate is not None and
> lastupdate < mtime".

You mean "lastupdate is None or lastupdate < mtime"? Otherwise, a file not present in the cache would never be looked-up.

Here's a patch.
It's obvious, but note that if the filesystem doesn't provide mtime, then once the metadata has been cached, it won't be refreshed if the file is updated.

I'll take a look around the standard library for similar issues.

Note: it would of course be simpler to use -1 as the default mtime value, but a negative time_t is possible.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22730/pydoc_mtime.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Sat Jul 23 19:52:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 17:52:40 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311443560.27.0.591535194447.issue12591@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: text files returned by subprocess.Popen with universal_newlines=True are not iterable -> TextIOWrapper should fall back on read() if read1() doesn't exist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 19:57:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 17:57:31 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311443851.93.0.604811673507.issue12591@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, as the title indicates, I think we should make TextIOWrapper work with raw IO objects. The reason is so that write() can behave in a totally unbuffered way, which is necessary for Popen to behave appropriately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 20:10:00 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 23 Jul 2011 18:10:00 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1311444600.74.0.197958818172.issue12600@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Having a "TestCase factory" would be pretty easy, and solve the scaling problems.

For example:

def make_testcase_classes():
    for backend in backends:
        yield type(
            '{}Test'.format(backend.name),
            (TheBaseClass, unittest.TestCase),
            {'backend': backend}
        )

You would use this in the load_tests function at the module level to generate all the test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12600>
_______________________________________

From report at bugs.python.org  Sat Jul 23 20:16:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 18:16:34 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311444994.72.0.718338679399.issue12591@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, one problem is that the C TextIOWrapper buffers writes. We would need an additional constructor parameter to prevent that :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 20:22:40 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Jul 2011 18:22:40 +0000
Subject: [issue12621] Errors in docstrings of find and rfind methods of bytes
	and bytestring
In-Reply-To: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
Message-ID: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

bytes.{find,rfind} reads s[start:end]; should be B[start:end]

bytearray.{find,rfind} reads s[start,end]; should be B[start:end]

{str,unicode}.{find,rfind} reads s{start:end]; should be S[start:end]

----------
assignee: docs at python
components: Documentation, Interpreter Core
keywords: easy
messages: 141001
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
stage: needs patch
status: open
title: Errors in docstrings of find and rfind methods of bytes and bytestring
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12621>
_______________________________________

From report at bugs.python.org  Sat Jul 23 20:33:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 18:33:06 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311445986.61.0.365554016042.issue12591@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another possibility is to provide read1() on RawIO, as a synonym of read().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:03:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 19:03:25 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311447805.71.0.801917545135.issue12591@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a first patch allowing TextIOWrapper to work with raw IO objects, and adding a "write_through" flag.

----------
keywords: +patch
Added file: http://bugs.python.org/file22731/textio_rawio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:08:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 19:08:28 +0000
Subject: [issue12622] failfast argument to TextTestRunner not documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://docs.python.org/dev/library/unittest.html#unittest.TextTestRunner doesn't mention the "failfast" argument, even though it's used by unittest.main().

----------
assignee: michael.foord
components: Documentation
messages: 141004
nosy: michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: failfast argument to TextTestRunner not documented
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12622>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:14:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Jul 2011 19:14:17 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311448457.82.0.825294800095.issue12591@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"write_through" is not used in _pyio.py, is it expected?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:17:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 19:17:13 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311448457.82.0.825294800095.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311448550.3001.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> "write_through" is not used in _pyio.py, is it expected?

Yup, because it is actually always write-through (writes are not
cached). The argument is only there so that the signature is the same as
the C version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:25:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Jul 2011 19:25:58 +0000
Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly
	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1311449158.51.0.16923709918.issue8714@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I know, the OpenBSD libpthread has problems. I listed some possible
candidates in #8712.

For instance:

http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/python/2.6/patches/Attic/patch-Lib_test_test_signal_py?rev=1.3;content-type=text%2Fplain


The comment says: "siginterrupt not reliable (does not mix well with threading"



To answer your questions:

1) Yes, there is only a single thread.

2) I only have an old OpenBSD 4.5, so it's not so useful to test
   there; I know Philip Guenther fixed some libpthread problems
   in the meantime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8714>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:37:33 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Jul 2011 19:37:33 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311449853.73.0.126630241766.issue12591@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Looks good, then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:41:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 19:41:37 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311450097.44.0.725918444572.issue12591@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This additional patch improves universal_newlines support in subprocess (still broken with the select- and poll-based loops in communicate()).

----------
Added file: http://bugs.python.org/file22732/spnewlines.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:43:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Jul 2011 19:43:18 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311450198.44.0.838925088212.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Eli, nice detective work. What I understand is that there was a latent platform-dependent buglet that presumably got exposed by a recent change in process handling, as Ned suggested.

idlelib/PyShell.py, class ModifiedInterpreter(InteractiveInterpreter) has
    def spawn_subprocess(self):
        if self.subprocess_arglist is None:
            self.subprocess_arglist = self.build_subprocess_arglist()
        args = self.subprocess_arglist
        self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args)

so IDLE expects the return to always be a pid which it is not.

Spawn_subprocess is called in both start_subprocess and restart_subprocess. Both now leave zombies on exit. I presume idlelib.run.main listens on the passed in port (in args) to make the connection. It appears to me that restart reuses the socket wrapped in self.rpcclt (rpc client).

Using subprocess.Popen seems like an good idea. The subprocess module is explicitly intended to replace low-level, fragile, difficult to get right, usage of os.spawn* and similar. If it does not work for this problem, *it* should be fixed.

On the other hand, IDLE uses sockets rather than pipes to communicate with subproccesses, perhaps because Windows pipes either are or were not as usable as unix pipes. Also, named or reusable pipes may not be usiversally available, so wrapping a pipe instead of a socket would, it seems to me, take more than simple replacement of spawnv by Popen.

Kurt, what do you think about possible fixes to this bug (critical for using IDLE on Windows)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:52:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 19:52:29 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <E1QkiFQ-0008LD-98@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9144014028f3 by Antoine Pitrou in branch '3.2':
Issue #12591: Allow io.TextIOWrapper to work with raw IO objects (without
http://hg.python.org/cpython/rev/9144014028f3

New changeset c3b47cdea0d1 by Antoine Pitrou in branch 'default':
Issue #12591: Allow io.TextIOWrapper to work with raw IO objects (without
http://hg.python.org/cpython/rev/c3b47cdea0d1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 21:58:55 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Jul 2011 19:58:55 +0000
Subject: [issue8714] Delayed signals in the REPL on OpenBSD (possibly
	libpthread related)
In-Reply-To: <1273854364.73.0.120471958938.issue8714@psf.upfronthosting.co.za>
Message-ID: <1311451135.88.0.85498770942.issue8714@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I forgot: readline support is enabled, and there are known problems:

http://marc.info/?t=128327329300003&r=1&w=2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8714>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:06:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 20:06:09 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <E1QkiSc-0000lV-7r@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5cc536fbd7c1 by Antoine Pitrou in branch '3.2':
Issue #12591: Improve support of "universal newlines" in the subprocess
http://hg.python.org/cpython/rev/5cc536fbd7c1

New changeset b616396fa170 by Antoine Pitrou in branch 'default':
Issue #12591: Improve support of "universal newlines" in the subprocess
http://hg.python.org/cpython/rev/b616396fa170

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:11:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:11:33 +0000
Subject: [issue12623] "universal newlines" subprocess support broken with
	select- and poll-based communicate()
In-Reply-To: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za>
Message-ID: <1311451893.22.0.0169745025507.issue12623@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The select() and poll() loop implementations of Popen.communicate() call os.write() instead of the write() method on the stdin pipe, meaning any newline translation *and* unicode-to-bytes encoding step is skipped.

To use the write() method on the stdin pipe, we may have to set the file descriptor in non-blocking mode, especially given that _PIPE_BUF worth of characters can amount to more than _PIPE_BUF bytes on the underlying raw fd.

See issue12591 for a simpler issue that was fixed.

----------
components: Library (Lib)
messages: 141014
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: "universal newlines" subprocess support broken with select- and poll-based communicate()
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12623>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:12:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:12:23 +0000
Subject: [issue12591] TextIOWrapper should fall back on read() if read1()
	doesn't exist
In-Reply-To: <1311139477.33.0.529664984261.issue12591@psf.upfronthosting.co.za>
Message-ID: <1311451943.8.0.229998291943.issue12591@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, this should be fixed now. universal newlines support is still broken with communicate(), I've opened issue12623 for that.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12591>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:25:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Jul 2011 20:25:08 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1311452708.7.0.884544953438.issue12170@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch with the following changes:

Allow an integer argument in range(0, 256) for the following bytes and
bytearray methods: count, find, index, rfind, rindex. Initially, only
count and index were targeted, but as index is implemented in a helper
function that is also used to implement find, rfind and rindex, these
functions were affected too.

The bytes methods were changed to use the new buffer protocol instead
of the deprecated PyObject_AsCharBuffer, for consistency with the
bytearray code.

Tests for all the modified functions were expanded to cover the new
functionality. While at it, the tests for count, index and rindex were
also further expanded (to test for slices, for example), as they were
initially quite minimal.

A paragraph describing the additional semantics of the five methods
was added to the documentation.

The error messages of index and rindex were left untouched
("substring not found" and "subsection not found"). In a case where
the first argument is an integer, the error messages could talk about
a byte instead of substring/subsection. This would have been a bit
non-straightforward to implement, so I didn't.

The docstrings were also left unchanged, as I couldn't find a good
wording for them. The problem is not that the first argument may now
be an integer, but as it can now be more than a substring or
subsection, we might have to specify what a substring or subsection
really means. And that explanation would be lengthy (because of the buffer protocol, that's not a concept that a regular Python programmer is, or even needs to be, familiar with)...

And finally, there's one thing that I'm unsure of:

When an integer out of range(0, 256) is passed as the first argument,
should we raise a ValueError or a TypeError? Currently, a ValueError
is raised, but this may be bad for index and rindex, as they raise a
ValueError when the substring or byte is not found. I made the
decision to raise a ValueError decision because __contains__ of both
bytes and bytearray raise a ValueError when passed an integer not in
range(0, 256).

----------
keywords: +needs review, patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file22733/issue12170.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:28:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:28:10 +0000
Subject: [issue12624] failfast support for regrtest
In-Reply-To: <1311452890.31.0.827101478258.issue12624@psf.upfronthosting.co.za>
Message-ID: <1311452890.31.0.827101478258.issue12624@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch adds a new --failfast (-G) argument to regrtest which stops running the tests as soon as a test fails (when using unittest-based test cases). Useful with long test suites such as test_io and test_subprocess.

----------
components: Tests
files: failfast.patch
keywords: patch
messages: 141017
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: failfast support for regrtest
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22734/failfast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12624>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:39:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jul 2011 20:39:25 +0000
Subject: [issue12624] failfast support for regrtest
In-Reply-To: <1311452890.31.0.827101478258.issue12624@psf.upfronthosting.co.za>
Message-ID: <E1Qkiyq-0002lP-4l@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9f847dfba217 by Antoine Pitrou in branch '3.2':
Issue #12624: It is now possible to fail after the first failure when
http://hg.python.org/cpython/rev/9f847dfba217

New changeset 01d18277c40b by Antoine Pitrou in branch 'default':
Issue #12624: It is now possible to fail after the first failure when
http://hg.python.org/cpython/rev/01d18277c40b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12624>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:40:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:40:02 +0000
Subject: [issue12624] failfast support for regrtest
In-Reply-To: <1311452890.31.0.827101478258.issue12624@psf.upfronthosting.co.za>
Message-ID: <1311453602.47.0.830347465369.issue12624@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12624>
_______________________________________

From report at bugs.python.org  Sat Jul 23 22:54:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 20:54:55 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <1311454495.5.0.801093056111.issue12625@psf.upfronthosting.co.za>
Message-ID: <1311454495.5.0.801093056111.issue12625@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Seen on an OpenIndiana buildbot:

======================================================================
FAIL: testInstallHandler (unittest.test.test_break.TestBreak)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.2.cea-indiana-amd64/build/Lib/unittest/test/test_break.py", line 37, in testInstallHandler
    self.assertTrue(unittest.signals._interrupt_handler.called)
AssertionError: False is not true

http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.2/builds/454/steps/test/logs/stdio


Probably something to do with signals behaviour under that particular OS.

----------
components: Library (Lib), Tests
messages: 141019
nosy: haypo, michael.foord, neologix, pitrou
priority: normal
severity: normal
status: open
title: sporadic test_unittest failure
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12625>
_______________________________________

From report at bugs.python.org  Sat Jul 23 23:10:08 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 23 Jul 2011 21:10:08 +0000
Subject: [issue12624] failfast support for regrtest
In-Reply-To: <1311452890.31.0.827101478258.issue12624@psf.upfronthosting.co.za>
Message-ID: <1311455408.9.0.895604105591.issue12624@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
resolution: invalid -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12624>
_______________________________________

From report at bugs.python.org  Sat Jul 23 23:21:56 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 23 Jul 2011 21:21:56 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1311456116.89.0.12268353098.issue10883@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Sat Jul 23 23:42:21 2011
From: report at bugs.python.org (python272)
Date: Sat, 23 Jul 2011 21:42:21 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1311457341.54.0.295035041311.issue12331@psf.upfronthosting.co.za>


python272 <letters.random13 at gmail.com> added the comment:

problem exists in python 2.7.2 (should this be reported as a separate issue?)

[Python-2.7.2]$ python -m test.regrtest  -v test_lib2to3
...
ERROR: test_bom (lib2to3.tests.test_refactor.TestRefactoringTool)
...
ERROR: test_crlf_newlines 
ERROR: test_file_encoding
ERROR: test_refactor_file
...

e.g.,

  File "/usr/local/lib/python2.7/lib2to3/tests/test_refactor.py", line 194, in check_file_refactoring
    with open(test_file, "wb") as fp:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/lib2to3/tests/data/fixers/parrot_example.py'
...
[test]# ls -l /usr/local/lib/python2.7/lib2to3/tests/data/fixers/parrot_example.py 
-rw-r--r-- 1 root root 23 2011-07-23 11:48 /usr/local/lib/python2.7/lib2to3/tests/data/fixers/parrot_example.py

----------
nosy: +python272

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12331>
_______________________________________

From report at bugs.python.org  Sat Jul 23 23:45:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Jul 2011 21:45:31 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1311457531.71.0.0323757828116.issue12331@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12331>
_______________________________________

From report at bugs.python.org  Sat Jul 23 23:46:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Jul 2011 21:46:56 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311457616.72.0.648031066015.issue12603@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.  Does this require a doc update, or is it entirely an internal function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Sat Jul 23 23:48:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 21:48:06 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch allows to only run tests which satisfy a glob filter, using the --match (-m) option to regrtest. For example:

  ./python -m test -m "*Signal*" -v test_io

will execute all the signal-related tests in test_io.

----------
components: Tests
files: regrtestglob.patch
keywords: patch
messages: 141022
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: run test cases based on a glob filter
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22735/regrtestglob.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sun Jul 24 01:00:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 23:00:49 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <1311454495.5.0.801093056111.issue12625@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3-XuxJhtzLrKBYyzw8NBbv0ararpY7jDfJMTGNe8_wFw@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Looks similar to issue #8263, which is in turn similar to #12469 (see
http://bugs.python.org/issue12469#msg139620 and
http://bugs.python.org/issue12469#msg139626 for original explanations):
normally, pending signals are checked when the process returns to
user-space, so a code like:

os.kill(os.getpid(), signum)
self.assertTrue(signum's handler called)

will succeed, because the signal is delivered before the kill()
syscall returns (it's actually required by POSIX), and the Python
signal handler will be called from the main eval loop before the assertion
test.
But if the signal isn't delivered right away (on FreeBSD6, it happens
only after a thread has been created, which explains #12469 and
probably #8263), then this check can fail (the signal will be
delivered typically when the next syscall returns, or at the next
timer interrupt, which could be after the test).

So I'd say the easier solution is to skip this test on OpenSolaris,
like it's done on FreeBSD6 since issue #8263.
Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file22736/indiana_signal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12625>
_______________________________________
-------------- next part --------------
diff -r cda93720c06d Lib/unittest/test/test_break.py
--- a/Lib/unittest/test/test_break.py	Sat Jul 23 18:15:43 2011 +0200
+++ b/Lib/unittest/test/test_break.py	Sun Jul 24 00:57:04 2011 +0200
@@ -9,9 +9,9 @@
 
 
 @unittest.skipUnless(hasattr(os, 'kill'), "Test requires os.kill")
- at unittest.skipIf(sys.platform =="win32", "Test cannot run on Windows")
- at unittest.skipIf(sys.platform == 'freebsd6', "Test kills regrtest on freebsd6 "
-    "if threads have been used")
+ at unittest.skipIf(sys.platform == 'win32', "Test cannot run on Windows")
+ at unittest.skipIf(sys.platform == 'freebsd6', "due to known OS bug")
+ at unittest.skipIf(sys.platform.startswith('sunos'), "due to known OS bug")
 class TestBreak(unittest.TestCase):
 
     def setUp(self):

From report at bugs.python.org  Sun Jul 24 01:02:36 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 23:02:36 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311457616.72.0.648031066015.issue12603@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0H5W5ZUmf5jxvXiPMQt0N+_J9_wpt65xS9M4OaTg3rvA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Well, the function is part of pydoc's public API, but the inner
working of the cache mechanism is completely private: this won't have
any impact, other than fixing the bug :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Sun Jul 24 01:13:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jul 2011 23:13:09 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <CAH_1eM3-XuxJhtzLrKBYyzw8NBbv0ararpY7jDfJMTGNe8_wFw@mail.gmail.com>
Message-ID: <CAH_1eM0N8SuMXRMaMUcdJ5rxnP02AdUi9aUwc1GidPZmf0HRrA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> So I'd say the easier solution is to skip this test on OpenSolaris,
> like it's done on FreeBSD6 since issue #8263.

Another option could be to add a dummy syscall, like os.getpid(),
before checking that the handler got called - this might be enough to
have the signal delivered.
Note that this kind of test assumes that the Python signal handler is
called right after the signal is delivered, i.e. every time from the
main eval loop (I think that's true with recent Python versions, is
that true with 2.7?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12625>
_______________________________________

From report at bugs.python.org  Sun Jul 24 01:15:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jul 2011 23:15:24 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <CAH_1eM0N8SuMXRMaMUcdJ5rxnP02AdUi9aUwc1GidPZmf0HRrA@mail.gmail.com>
Message-ID: <1311462842.3001.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Note that this kind of test assumes that the Python signal handler is
> called right after the signal is delivered, i.e. every time from the
> main eval loop (I think that's true with recent Python versions, is
> that true with 2.7?).

No, it's a feature of the new GIL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12625>
_______________________________________

From report at bugs.python.org  Sun Jul 24 02:14:33 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 24 Jul 2011 00:14:33 +0000
Subject: [issue12621] Errors in docstrings of find and rfind methods of bytes
	and bytestring
In-Reply-To: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
Message-ID: <1311466473.05.0.845467199697.issue12621@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

These are not on head revision in cpython and 3.2. Where did you find this bug? Please provide further details along with snippet and/or file.

----------
nosy: +orsenthil
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12621>
_______________________________________

From report at bugs.python.org  Sun Jul 24 02:43:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Jul 2011 00:43:25 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <E1Qkmmv-0003Eq-W2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 92d02de91cc9 by Antoine Pitrou in branch '3.2':
Issue #1813: Fix codec lookup under Turkish locales.
http://hg.python.org/cpython/rev/92d02de91cc9

New changeset a77a4df54b95 by Antoine Pitrou in branch '3.2':
Add a test for issue #1813: getlocale() failing under a Turkish locale
http://hg.python.org/cpython/rev/a77a4df54b95

New changeset fe0caf8c48d2 by Antoine Pitrou in branch 'default':
Add a test for issue #1813: getlocale() failing under a Turkish locale
http://hg.python.org/cpython/rev/fe0caf8c48d2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Sun Jul 24 02:52:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Jul 2011 00:52:27 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <E1Qkmvi-0003us-4U@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 739958134fe5 by Antoine Pitrou in branch '2.7':
Issue #1813: Fix codec lookup and setting/getting locales under Turkish locales.
http://hg.python.org/cpython/rev/739958134fe5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Sun Jul 24 02:53:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Jul 2011 00:53:04 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1311468784.72.0.0892722420009.issue1813@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Finally fixed in 2.7, 3.2, 3.3!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Sun Jul 24 03:16:38 2011
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 24 Jul 2011 01:16:38 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1311470198.3.0.868023122112.issue10044@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/issue10044>
_______________________________________

From report at bugs.python.org  Sun Jul 24 03:45:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jul 2011 01:45:31 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1311471931.01.0.76187398314.issue12626@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #12231 for a similar suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sun Jul 24 03:46:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jul 2011 01:46:01 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1311471961.96.0.920879725304.issue12231@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #12626 for a similar suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12231>
_______________________________________

From report at bugs.python.org  Sun Jul 24 04:05:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jul 2011 02:05:05 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1311473105.36.0.580086293798.issue12170@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> When an integer out of range(0, 256) is passed as the first argument,
> should we raise a ValueError or a TypeError?

ValueError = Inappropriate argument value (of correct type).
TypeError = Inappropriate argument type.

> Currently, a ValueError raised, but this may be bad for index and 
> rindex, as they raise a ValueError when the substring or byte is not found.

Then the users should check if the value is in range(256) before passing it to (r)index.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Sun Jul 24 04:31:35 2011
From: report at bugs.python.org (Kerrick Staley)
Date: Sun, 24 Jul 2011 02:31:35 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>


New submission from Kerrick Staley <mail at kerrickstaley.com>:

This issue was opened to track the implementation of PEP 394, which governs the way the python command and commands like python2 and python3 work on Unix-like systems.

----------
components: Installation
messages: 141034
nosy: Kerrick.Staley
priority: normal
severity: normal
status: open
title: Implement PEP 394: The "python" Command on Unix-Like Systems
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Jul 24 04:39:47 2011
From: report at bugs.python.org (Kerrick Staley)
Date: Sun, 24 Jul 2011 02:39:47 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1311475187.58.0.207108887156.issue12627@psf.upfronthosting.co.za>


Kerrick Staley <mail at kerrickstaley.com> added the comment:

Here is a patch that will update the Makefile.pre.in file for 2.7, causing it to install python2 and python2-config when run with "make install" (or just "make bininstall"). This does not update any documentation. Also, it appears that Idle and PyDoc are not installed by the 2.7 Makefile, so I didn't do anything about those, even though the PEP mentions them.

----------
keywords: +patch
Added file: http://bugs.python.org/file22737/version27_links.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Jul 24 04:42:02 2011
From: report at bugs.python.org (Kerrick Staley)
Date: Sun, 24 Jul 2011 02:42:02 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1311475322.91.0.00960641721556.issue12627@psf.upfronthosting.co.za>


Kerrick Staley <mail at kerrickstaley.com> added the comment:

This updates the links created by "make install" or "make bininstall" in Python 3 so that they're in agreement with the recommendations of PEP 394; it's the equivalent of version27_links.patch but is for Python 3.

----------
Added file: http://bugs.python.org/file22738/version33_links.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Jul 24 04:43:18 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Jul 2011 02:43:18 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1311475398.22.0.287134424313.issue12627@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Jul 24 05:05:26 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 24 Jul 2011 03:05:26 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311476726.92.0.591413042049.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry,

What still bugs me is that it isn't clear what change from 3.2 to 3.2.1 caused this problem to manifest.

Also, I'm not sure why you mention the sockets vs. pipes issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sun Jul 24 05:08:21 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 24 Jul 2011 03:08:21 +0000
Subject: [issue5441] Convenience API for timeit.main
In-Reply-To: <1236492146.81.0.454674408295.issue5441@psf.upfronthosting.co.za>
Message-ID: <1311476901.19.0.804227563907.issue5441@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/issue5441>
_______________________________________

From report at bugs.python.org  Sun Jul 24 05:16:24 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 24 Jul 2011 03:16:24 +0000
Subject: [issue1397474] timeit execution enviroment
Message-ID: <1311477384.29.0.263286431422.issue1397474@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry, I'd like to move this forward. New interfaces or not, making the documentation more comprehensible is an important goal in itself.

Could you please comment on rurpy2's latest notes - I will adapt the patch for latest 2.7/3.2/3.3 heads and commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1397474>
_______________________________________

From report at bugs.python.org  Sun Jul 24 05:20:21 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 24 Jul 2011 03:20:21 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1311477621.74.0.619831082024.issue12043@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/issue12043>
_______________________________________

From report at bugs.python.org  Sun Jul 24 05:21:26 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 24 Jul 2011 03:21:26 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1311477686.13.0.974823165834.issue2091@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/issue2091>
_______________________________________

From report at bugs.python.org  Sun Jul 24 07:12:20 2011
From: report at bugs.python.org (Roy Liu)
Date: Sun, 24 Jul 2011 05:12:20 +0000
Subject: [issue12628] urllib.request.urlopen gives empty response bodies for
	some sites
In-Reply-To: <1311484340.86.0.612332840201.issue12628@psf.upfronthosting.co.za>
Message-ID: <1311484340.86.0.612332840201.issue12628@psf.upfronthosting.co.za>


New submission from Roy Liu <carsomyr at gmail.com>:

When testing urllib.request.urlopen in Python 3, I found that it gave empty responses for some sites. In other words, reading from the file-like object gives zero bytes. Python 2.x's urllib2.urlopen did not give this behavior. I isolated the problem down to the following difference:

@@ -1137,8 +1137,6 @@
             r = h.getresponse()  # an HTTPResponse instance
         except socket.error as err:
             raise URLError(err)
-        finally:
-            h.close()
 
         r.url = req.get_full_url()
         # This line replaces the .msg attribute of the HTTPResponse

The "finally" clause is absent in urllib2.py but present in Python 3.2's request.py. I think it has something to do with the HTTPConnection being closed before data could be read. Still, it's puzzling because some sites still give expected answers. Please find attached a small test script for "www.wsj.com" for which the response body should be empty without applying the above patch.

----------
components: Extension Modules
files: test.py
messages: 141039
nosy: royliu
priority: normal
severity: normal
status: open
title: urllib.request.urlopen gives empty response bodies for some sites
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22739/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12628>
_______________________________________

From report at bugs.python.org  Sun Jul 24 07:17:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jul 2011 05:17:42 +0000
Subject: [issue12628] urllib.request.urlopen gives empty response bodies for
	some sites
In-Reply-To: <1311484340.86.0.612332840201.issue12628@psf.upfronthosting.co.za>
Message-ID: <1311484662.17.0.837028592685.issue12628@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Duplicate of #12576.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> urlib.request fails to open some sites

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12628>
_______________________________________

From report at bugs.python.org  Sun Jul 24 12:53:50 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 10:53:50 +0000
Subject: [issue12621] Errors in docstrings of find and rfind methods of bytes
	and bytestring
In-Reply-To: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
Message-ID: <1311504830.94.0.820201265539.issue12621@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached outputs of the following commands in the corresponding head revisions (from yesterday, as hg.python.org seems to be down today):

3.3:

for x in {bytes,bytearray}.{find,rfind} str.{find,rfind}; do echo === $x ===; ./python -c "help($x)" | cat; echo; done > 3.3.txt

3.2:

for x in {bytes,bytearray}.{find,rfind} str.{find,rfind}; do echo === $x ===; ./python -c "help($x)" | cat; echo; done > 3.2.txt

2.7:

for x in bytearray.{find,rfind} unicode.{find,rfind}; do echo === $x ===; ./python -c "help($x)" | cat; echo; done > 2.7.txt


In all files, I see s[start:end] or s[start,end] where there should read B[start:end] or S[start:end].

----------
stage:  -> needs patch
Added file: http://bugs.python.org/file22740/3.3.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12621>
_______________________________________

From report at bugs.python.org  Sun Jul 24 12:57:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 10:57:43 +0000
Subject: [issue12621] Errors in docstrings of find and rfind methods of bytes
	and bytestring
In-Reply-To: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
Message-ID: <1311505063.57.0.662540182559.issue12621@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Added file: http://bugs.python.org/file22741/3.2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12621>
_______________________________________

From report at bugs.python.org  Sun Jul 24 12:59:48 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 10:59:48 +0000
Subject: [issue12621] Errors in docstrings of find and rfind methods of bytes
	and bytestring
In-Reply-To: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
Message-ID: <1311505188.68.0.775677103287.issue12621@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Added file: http://bugs.python.org/file22742/2.7.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12621>
_______________________________________

From senthil at uthcode.com  Sun Jul 24 13:03:03 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 24 Jul 2011 19:03:03 +0800
Subject: [issue12621] Errors in docstrings of find and rfind methods of
	bytes and bytestring
In-Reply-To: <1311504830.94.0.820201265539.issue12621@psf.upfronthosting.co.za>
References: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
	<1311504830.94.0.820201265539.issue12621@psf.upfronthosting.co.za>
Message-ID: <20110724110303.GA3283@mathmagic>

Okay, got it. Thanks. I was a subtle one within the description. I
missed it in the first place.

From report at bugs.python.org  Sun Jul 24 13:03:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 24 Jul 2011 11:03:12 +0000
Subject: [issue12621] Errors in docstrings of find and rfind methods of bytes
	and bytestring
In-Reply-To: <1311504830.94.0.820201265539.issue12621@psf.upfronthosting.co.za>
Message-ID: <20110724110303.GA3283@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Okay, got it. Thanks. I was a subtle one within the description. I
missed it in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12621>
_______________________________________

From report at bugs.python.org  Sun Jul 24 14:32:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Jul 2011 12:32:31 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <1311462842.3001.10.camel@localhost.localdomain>
Message-ID: <CAH_1eM27amMVKH0k9wvNB79b_=vd0WG8x5EKV==iXP06nScnLA@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> No, it's a feature of the new GIL.

When I look at 2.7's code, I see something different - _Py_Ticker is
reset in Py_AddPendingCall():

int
Py_AddPendingCall(int (*func)(void *), void *arg)
{
[...]
    /* signal main loop */
    _Py_Ticker = 0;
    pendingcalls_to_do = 1;
[...]
}

And there's a comment in the main eval loop which confirms this:
        /* Do periodic things.  Doing this every time through
           the loop would add too much overhead, so we do it
           only every Nth instruction.  We also do it if
           ``pendingcalls_to_do'' is set, i.e. when an asynchronous
           event needs attention (e.g. a signal handler or
           async I/O handler); see Py_AddPendingCall() and
           Py_MakePendingCalls() above. */

So, AFAICT, signal handlers will get called right away (and if I
remove the _Py_Ticker reset from Py_AddPendingCall(), then those tests
fail consistently on Linux).
Or am I missing something?

Concerning the original problem, here's a patch implementing the second idea:
- getpid() is called after each kill(getpid(), <signum>), to "force"
the signal delivery
- the test is now re-enabled on FreeBSD6

I think this should fx the problem on both FreeBSD6 and OpenSolaris,
but since I don't have a FreeBSD or OpenSolaris box at hand, I
couldn't test it. Shall I try to commit it and see what the buildbots
say?

----------
Added file: http://bugs.python.org/file22743/kill_delayed_signal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12625>
_______________________________________
-------------- next part --------------
diff -r cda93720c06d Lib/unittest/test/test_break.py
--- a/Lib/unittest/test/test_break.py	Sat Jul 23 18:15:43 2011 +0200
+++ b/Lib/unittest/test/test_break.py	Sun Jul 24 14:23:32 2011 +0200
@@ -10,8 +10,6 @@
 
 @unittest.skipUnless(hasattr(os, 'kill'), "Test requires os.kill")
 @unittest.skipIf(sys.platform =="win32", "Test cannot run on Windows")
- at unittest.skipIf(sys.platform == 'freebsd6', "Test kills regrtest on freebsd6 "
-    "if threads have been used")
 class TestBreak(unittest.TestCase):
 
     def setUp(self):
@@ -29,8 +27,15 @@
         self.assertNotEqual(signal.getsignal(signal.SIGINT), default_handler)
 
         try:
+            # When a process sends a signal to itself, POSIX states that the
+            # signal must be delivered before the kill() syscall returns. Some
+            # operating systems are known to delay signal delivery in this
+            # situation (see issues #12625, #8263 and #12469): to force the
+            # signal's delivery, we make a dummy getpid() syscall (signals are
+            # typically delivered when the process returns to user-space).
             pid = os.getpid()
             os.kill(pid, signal.SIGINT)
+            os.getpid()
         except KeyboardInterrupt:
             self.fail("KeyboardInterrupt not handled")
 
@@ -61,6 +66,7 @@
         def test(result):
             pid = os.getpid()
             os.kill(pid, signal.SIGINT)
+            os.getpid()
             result.breakCaught = True
             self.assertTrue(result.shouldStop)
 
@@ -79,9 +85,11 @@
         def test(result):
             pid = os.getpid()
             os.kill(pid, signal.SIGINT)
+            os.getpid()
             result.breakCaught = True
             self.assertTrue(result.shouldStop)
             os.kill(pid, signal.SIGINT)
+            os.getpid()
             self.fail("Second KeyboardInterrupt not raised")
 
         try:
@@ -109,6 +117,7 @@
         def test(result):
             pid = os.getpid()
             os.kill(pid, signal.SIGINT)
+            os.getpid()
 
         try:
             test(result)
@@ -134,6 +143,7 @@
         try:
             pid = os.getpid()
             os.kill(pid, signal.SIGINT)
+            os.getpid()
         except KeyboardInterrupt:
             pass
         else:
@@ -173,6 +183,7 @@
         try:
             pid = os.getpid()
             os.kill(pid, signal.SIGINT)
+            os.getpid()
         except KeyboardInterrupt:
             pass
 

From report at bugs.python.org  Sun Jul 24 14:39:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Jul 2011 12:39:37 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1311511177.76.0.0368182216673.issue12560@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The patch looks good to me.
As for the other failures, it would probably be interesting to open a
separate issue, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Sun Jul 24 16:29:18 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 24 Jul 2011 14:29:18 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1311517758.6.0.482411805257.issue12626@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I love the functionality. Running individual tests (or groups of tests) with unittest is a *pain*. I had hoped to solve this through unittest extensions, but this is taking me longer to get to than I had hoped.

So I would like to add this to unittest, but obviously that can't happen for 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sun Jul 24 17:09:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Jul 2011 15:09:19 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1311520159.6.0.572739796007.issue12627@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Some scripts are installed by setup.py

I?ll find time to read the latest version of the PEP in the coming days.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Jul 24 17:10:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Jul 2011 15:10:09 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311520209.88.0.740747152968.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You haven?t set the git option for the diff commands in your config file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sun Jul 24 17:19:09 2011
From: report at bugs.python.org (higery)
Date: Sun, 24 Jul 2011 15:19:09 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1311520209.88.0.740747152968.issue12394@psf.upfronthosting.co.za>
Message-ID: <CAHGir+GfF_+UcA-ntS+M2EuH5Dv=3auQ=Kn6M_eHLMOgYcMnSQ@mail.gmail.com>


higery <shoulderhigher at gmail.com> added the comment:

remote repository? It's just a configuration file under the .hg directory...

----------
Added file: http://bugs.python.org/file22744/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________
-------------- next part --------------
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">

</div>You haven???t set the git option for the diff commands in your config file.<br><br></blockquote><div>I have already set the option as you said earlier, but how to &#39;push&#39; it to remote repository? It&#39;s just a configuration file under the .hg directory...<br>
<br><br>??<br></div></div>

From report at bugs.python.org  Sun Jul 24 19:43:34 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 17:43:34 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1311529414.27.0.116758491125.issue12627@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12627>
_______________________________________

From report at bugs.python.org  Sun Jul 24 19:54:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 17:54:36 +0000
Subject: [issue11784] multiprocessing.Process.join: timeout argument doesn't
	specify time unit.
In-Reply-To: <1302102892.38.0.716462659094.issue11784@psf.upfronthosting.co.za>
Message-ID: <1311530076.73.0.485963744575.issue11784@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11784>
_______________________________________

From report at bugs.python.org  Sun Jul 24 19:55:44 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 17:55:44 +0000
Subject: [issue12294] multiprocessing.Pool: Need a way to find out if work are
	finished.
In-Reply-To: <1307627992.49.0.467043384727.issue12294@psf.upfronthosting.co.za>
Message-ID: <1311530144.06.0.303126233026.issue12294@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12294>
_______________________________________

From report at bugs.python.org  Sun Jul 24 19:57:02 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 17:57:02 +0000
Subject: [issue12063] tokenize module appears to treat unterminated single and
	double-quoted strings inconsistently
In-Reply-To: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>
Message-ID: <1311530222.89.0.40158897592.issue12063@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12063>
_______________________________________

From report at bugs.python.org  Sun Jul 24 19:58:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 17:58:43 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1311530323.73.0.815119221106.issue12174@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +needs review
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Sun Jul 24 20:09:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 18:09:21 +0000
Subject: [issue11934] build with --prefix=/dev/null and zlib enabled in
	Modules/Setup failed
In-Reply-To: <1303898972.2.0.53608607185.issue11934@psf.upfronthosting.co.za>
Message-ID: <1311530961.74.0.766058353962.issue11934@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

ysj.ray:

As you're on Debian, the real cause of this might be issue 11715. The Modules/Setup.dist line for zlib is commented out, so it's only an example of how to enable zlib if it's not found automatically.

Can you try again now that issue 11715 has been fixed?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11934>
_______________________________________

From report at bugs.python.org  Sun Jul 24 20:22:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 18:22:15 +0000
Subject: [issue11708] argparse: suggestion for formatting optional positional
	args
In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za>
Message-ID: <1311531735.79.0.943092620706.issue11708@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I think this is a good idea, and seems to me more like a bug than a feature request.

----------
stage:  -> needs patch
type: feature request -> 
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11708>
_______________________________________

From report at bugs.python.org  Sun Jul 24 20:26:12 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 18:26:12 +0000
Subject: [issue11694] xdrlib raises ConversionError in inconsistent way
In-Reply-To: <1301224336.99.0.411299821684.issue11694@psf.upfronthosting.co.za>
Message-ID: <1311531972.72.0.399218896328.issue11694@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage:  -> test needed
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11694>
_______________________________________

From report at bugs.python.org  Sun Jul 24 20:27:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 18:27:15 +0000
Subject: [issue11869] Include information about the bug tracker Rietveld code
	review tool
In-Reply-To: <1303156808.41.0.477083927136.issue11869@psf.upfronthosting.co.za>
Message-ID: <1311532035.87.0.788362554404.issue11869@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11869>
_______________________________________

From report at bugs.python.org  Sun Jul 24 20:35:07 2011
From: report at bugs.python.org (Kevin Stock)
Date: Sun, 24 Jul 2011 18:35:07 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>


New submission from Kevin Stock <teoryn at gmail.com>:

Given the input '<x><y z=""o"" /></x>', HTMLParser only detects the opening x tag, and then stops parsing. Ideally this should behave like the case '<x><y z="""" /></x>' which raises an error and then can continue parsing the close x tag.

----------
components: Library (Lib)
files: test.py
messages: 141051
nosy: teoryn
priority: normal
severity: normal
status: open
title: HTMLParser silently stops parsing with malformed attributes
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22745/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12629>
_______________________________________

From report at bugs.python.org  Sun Jul 24 20:55:39 2011
From: report at bugs.python.org (Marc Culler)
Date: Sun, 24 Jul 2011 18:55:39 +0000
Subject: [issue10731] UnicodeDecodeError in OS X tkinter when binding to
	<MouseWheel>
In-Reply-To: <1292685761.16.0.751551658727.issue10731@psf.upfronthosting.co.za>
Message-ID: <1311533739.36.0.347234120453.issue10731@psf.upfronthosting.co.za>


Marc Culler <culler at math.uic.edu> added the comment:

I am running OSX 10.5.8 on this macbook.  The Tcl/Tk package on the system is ActiveState Tcl/Tk 8.4.19.

I just installed Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) from http://www.python.org/getit/releases/3.2/ and I am still seeing this bug.  It does not occur with the Python 2.7 Tkinter package, which uses the same Tcl/Tk framework.  So if it is a bug in Tk, it is harmless when used with Python 2.7.  But, after all, it is not so surprising to see new UnicodeDecodeErrors when porting from Python 2 to Python 3.

----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10731>
_______________________________________

From report at bugs.python.org  Sun Jul 24 21:44:25 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Jul 2011 19:44:25 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <1311536665.07.0.0194411467062.issue12448@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12448>
_______________________________________

From report at bugs.python.org  Sun Jul 24 22:33:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Jul 2011 20:33:38 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <E1Ql5Mg-0002EX-Kt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 33be4896003a by Charles-Fran?ois Natali in branch '2.7':
Issue #12560: Build libpython.so on OpenBSD. Patch by Stefan Sperling.
http://hg.python.org/cpython/rev/33be4896003a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Sun Jul 24 22:41:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Jul 2011 20:41:24 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <E1Ql5UI-0002mJ-Lm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1fdad36ac838 by Charles-Fran?ois Natali in branch '3.2':
Issue #12560: Build libpython.so on OpenBSD. Patch by Stefan Sperling.
http://hg.python.org/cpython/rev/1fdad36ac838

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Sun Jul 24 22:43:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Jul 2011 20:43:59 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <E1Ql5Wo-0002ry-84@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a095cbed24c3 by Charles-Fran?ois Natali in branch 'default':
Issue #12560: Build libpython.so on OpenBSD. Patch by Stefan Sperling.
http://hg.python.org/cpython/rev/a095cbed24c3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Sun Jul 24 22:46:52 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Jul 2011 20:46:52 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1311540412.73.0.0426538848222.issue12560@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed.
Stefan, thanks for the report and the patch!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Sun Jul 24 22:51:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Jul 2011 20:51:18 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1311540678.07.0.080079698738.issue12498@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello,

> Actually the class asyncore.dispatcher_with_send do not handle properly
> disconnection. When the endpoint shutdown his sending part of the socket,
> but keep the socket open in reading, the current implementation of
> dispatcher_with_send will close the socket without sending pending data.

Yes, that's a common problem with "naive" networking code.

> Note also that this class try to initiate a send even if the socket is maybe
> not ready for writing:
>
> Here's a simple fix:
>     def send(self, data):
>         if self.debug:
>             self.log_info('sending %s' % repr(data))
>         self.out_buffer = self.out_buffer + data
> -       self.initiate_send()
>

Hum, I'm not sure about this.
dispatcher is just a thin wrapper around the underlying socket, so the
semantic of `send` should be the same as `socket.send`, i.e. just call
the send(2) syscall. I think it's the application's reponsibility to
check that the socket is indeed writable, and to cope with potential
failures (e.g. EAGAIN or ENOTCONN).

> Last but not last, the buffer size of each socket send are way to small
> (512, a third of an usual TCP frame). Here's the code with a bumped value:

Indeed, 1/3 of the ethernet MTU is quite small.

Would you like to submit a patch?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Jul 24 22:52:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Jul 2011 20:52:01 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1309830930.03.0.793190602228.issue12498@psf.upfronthosting.co.za>
Message-ID: <1311540721.12.0.211545067327.issue12498@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
components: +Library (Lib) -IO
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12498>
_______________________________________

From report at bugs.python.org  Sun Jul 24 22:54:39 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Jul 2011 20:54:39 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1311125590.66.0.0933239055495.issue10141@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2VTLZV0_Vn3U4u_RqFr9eYUw10DuEnsar7jVCp=wreOw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks for updating your patch.
I've done a review, available here:
http://bugs.python.org/review/10141/show

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Sun Jul 24 23:33:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Jul 2011 21:33:53 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311543233.39.0.336494029945.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22744/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Sun Jul 24 23:35:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Jul 2011 21:35:57 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311543357.58.0.424099641032.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

higery?s message was this:

> I have already set the option as you said earlier, but how to
> 'push' it to remote repository? It's just a configuration file under
> the .hg directory...

I was mistaken; setting the diff git option is important if you generate patches from your clone, but this does not matter with the automatic generation.  I?ll open a report on the metatracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Mon Jul 25 00:09:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Jul 2011 22:09:02 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311545342.99.0.629693158367.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I mentioned pipes because half of the subprocess chapter, it seems, talks about them. ASo I got the mis-impression that they are special for subprocess-started processes. But if the subprocess gets the args it needs to connect to a socket, it should not care how it is started.

Anyway, some experiments:

3.1.3 and 3.1.4 freshly installed do not seem to have the zombie problem. This seems to rule out the possibility that the problem is due to recent patches from Microsoft.

I redeleted 3.2 installation and re-installed 3.2. Sys.version still mistakingly say 3.2.1, July 10., so there is something different about the relationship between 3.2 and 3.2.1 and that between 3.1.3 and 3.1.4. And the 3.2 re-install has the zombie problem while I do not believe the fresh 3.2 install did. (And it does not on my other machine.) But I do not see how something stuck in the registry could affect process killing.

In the notepad example, changing

pid = os.spawnv(os.P_NOWAIT, 'C:/WINDOWS/notepad.exe', ['notepad.exe'])
# (full path needed if not in /windows) to
pid = subprocess.Popen(['C:/WINDOWS/notepad.exe']).pid

changed the 'pid' from a constant (across multiple runs) to a variable (across multiple runs) and changed the result of the kill from a zombie and exception to proper termination.

When I tried the same fix in idlelib/PyShell.py, adding 'import subprocess' and changing
        self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args)
to
        self.rpcpid = subprocess.Popen(args).pid
(args begins with sys.executable) IDLE failed to start. The only evidence that it had been invoked was a brief (1/4 second?) appearance of 1 pythonw process in task manager. On a subsequent tries, without touching the file, I do not see even that. Is there any obvious mistake in the above?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Mon Jul 25 00:26:05 2011
From: report at bugs.python.org (Eric Snow)
Date: Sun, 24 Jul 2011 22:26:05 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1311546365.24.0.956299647381.issue12626@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Mon Jul 25 01:05:00 2011
From: report at bugs.python.org (tkiss80)
Date: Sun, 24 Jul 2011 23:05:00 +0000
Subject: [issue12630] pydoc does not remove '#'-s from doc comments
In-Reply-To: <1311548700.89.0.657910750952.issue12630@psf.upfronthosting.co.za>
Message-ID: <1311548700.89.0.657910750952.issue12630@psf.upfronthosting.co.za>


New submission from tkiss80 <tkiss80 at gmail.com>:

If an entity does not have a docstring, pydoc.getdoc() reads the comment associated with that entity and uses that as the source of documentation. However, inspect.getcomments() returns the raw comment with the comment signs ('#') in it, thus the resulting documentation looks ugly and confusing. Is there a way to solve this problem?

I know that this is not an easy task, because by implementing a specific '#' removing solution, the format of the doc comments would be restricted to conform to that algorithm with little formatting freedom. But maybe someone can come up with a good idea, such as counting '#'-s in the first line and strip all the lines accordingly.

----------
messages: 141061
nosy: tkiss80
priority: normal
severity: normal
status: open
title: pydoc does not remove '#'-s from doc comments
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12630>
_______________________________________

From report at bugs.python.org  Mon Jul 25 01:22:19 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Jul 2011 23:22:19 +0000
Subject: [issue12630] pydoc does not remove '#'-s from doc comments
In-Reply-To: <1311548700.89.0.657910750952.issue12630@psf.upfronthosting.co.za>
Message-ID: <1311549739.61.0.0518494402825.issue12630@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The best solution is to modify the offending code to use real docstrings.

Failing that, a simple explicit "'\n'.join(line.lstrip('#' for line in comment.split('\n'))" (i.e. not as part of pydoc) will handle most cases.

Anything more sophisticated would need to be tailored to the comment format of the code that is missing docstrings.

----------
nosy: +ncoghlan
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12630>
_______________________________________

From report at bugs.python.org  Mon Jul 25 01:24:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Jul 2011 23:24:33 +0000
Subject: [issue12448] smtplib's __main__ doesn't flush when prompting
In-Reply-To: <1309414826.92.0.939740795599.issue12448@psf.upfronthosting.co.za>
Message-ID: <1311549873.05.0.792666230865.issue12448@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Looks good.
Thx.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12448>
_______________________________________

From report at bugs.python.org  Mon Jul 25 01:41:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Jul 2011 23:41:21 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311550881.66.0.321221808117.issue12618@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's rare to receive fixes from Windows users that don't have a dev environment set up (i.e. they just edited their stdlib code in place, or copied it and created a modified version). Thanks for persisting in the face of invalid assumptions on our part.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Mon Jul 25 02:04:35 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 25 Jul 2011 00:04:35 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311552275.23.0.416739205161.issue12576@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I propose the attached patch as fix to this issue. All it does is, moves the code of getting http response to the finally block of the http request. It closes the sockets if the getting the response fails for some reason, otherwise it proceeds normally.  

Please provide your critique if any, otherwise, I shall go ahead with checking this in.

----------
keywords: +patch
Added file: http://bugs.python.org/file22746/issue12576.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Mon Jul 25 02:26:30 2011
From: report at bugs.python.org (py.user)
Date: Mon, 25 Jul 2011 00:26:30 +0000
Subject: [issue12631] Mutable Sequence Type in .remove() is consistent only
	with lists, but not with bytearrays
In-Reply-To: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>
Message-ID: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

4.6.4 Mutable Sequence Types

|  s.remove(x)  |  same as del s[s.index(x)]  |


>>> b = bytearray()
>>> b.extend(range(1, 6))
>>> b
bytearray(b'\x01\x02\x03\x04\x05')
>>> b.remove(2)
>>> del b[b.index(2)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Type int doesn't support the buffer API
>>>

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 141066
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: Mutable Sequence Type in .remove() is consistent only with lists, but not with bytearrays
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12631>
_______________________________________

From report at bugs.python.org  Mon Jul 25 02:26:57 2011
From: report at bugs.python.org (py.user)
Date: Mon, 25 Jul 2011 00:26:57 +0000
Subject: [issue12631] Mutable Sequence Type in .remove() is consistent only
	with lists, but not with bytearrays
In-Reply-To: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>
Message-ID: <1311553617.98.0.275569919083.issue12631@psf.upfronthosting.co.za>


Changes by py.user <port139 at yandex.ru>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12631>
_______________________________________

From report at bugs.python.org  Mon Jul 25 04:24:49 2011
From: report at bugs.python.org (Bruce Ferris)
Date: Mon, 25 Jul 2011 02:24:49 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>


New submission from Bruce Ferris <bferris57 at bferris.co.uk>:

The following scenario GPFs on Windows Vista using cmd.exe...

  D:\>python
  Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
   (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> ^Z

  D:\>chcp 65001
  Active code page: 65001

  D:\>python
  Fatal Python error: Py_Initialize: can't initialize sys standard
   streams
  LookupError: unknown encoding: cp65001

  This application has requested the Runtime to terminate it in an 
  unusual way.
  Please contact the application's support team for more information.

  D:\>

This is a bit surprising since Code Page 65001 IS the official Microsoft UTF-8 Code Page.

Please see...

  http://msdn.microsoft.com/en-us/library/dd317756%28v=vs.85%29.aspx

----------
components: Unicode
messages: 141067
nosy: bferris57
priority: normal
severity: normal
status: open
title: Windows GPF with Code Page 65001
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 04:25:43 2011
From: report at bugs.python.org (Bruce Ferris)
Date: Mon, 25 Jul 2011 02:25:43 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311560743.45.0.305583801654.issue12632@psf.upfronthosting.co.za>


Changes by Bruce Ferris <bferris57 at bferris.co.uk>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 04:33:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jul 2011 02:33:18 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311561198.21.0.122977458503.issue12632@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 06:49:51 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 25 Jul 2011 04:49:51 +0000
Subject: [issue12633] sys.modules gets special treatment
In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>
Message-ID: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The sys.modules dict is a special object.  It is the only variable of the CPython interpreter object that is exposed in the sys module[1].  Everything else in sys lives in the module.  However, the modules dict lives in the interpreter object and is bound to the sys module separately.  No other variable of the interpreter object gets this treatment.

This situation sets up an unexpected behavior for sys.modules.  There are many places, mostly in Python/import.c, where the modules dict gets used and not by pulling from sys.modules.  These places use interp->modules directly[2].  So if sys.modules is re-bound, the imp module is using/reporting an out of sync modules dict.

One could argue that re-binding a module global is risky and should be avoided.  I agree.  Here is the use case that prompted me to march ahead anyway:

class BaseTest(TestCase):
    @classmethod
    def setUpClass(cls):
        cls.sysmodules = sys.modules
        sys.modules = sys.modules.copy()
    @classmethod
    def tearDownClass(cls):
        sys.modules = cls.sysmodules

I was writing some import related tests and wanted sys.modules to be returned to its initial state after each test.  I realise that Lib/test/support.py provides CleanImport and others address this, but you have to provide the module names to clean up.  This is an unfortunate hassle sometimes when several layers of imports happen during the import of the module you care about.

So the result was an exception when I tried importing an extension module, like "_sqlite3".  This is because in importdl.h the new module is added to the dict returned by PyImport_GetModuleDict(), not to the one at sys.modules.

For now I am doing the following to get the same effect:

class BaseTest(TestCase):
    @classmethod
    def setUpClass(cls):
        cls.sysmodules = sys.modules.copy()
    @classmethod
    def tearDownClass(cls):
        for name in sys.modules:
            del sys.modules[name]
        for name in cls.sysmodules:
            sys.modules[name] = cls.sysmodules[name]

However, this is less efficient, sort of.  I expect that the current direct use of interp->modules in the CPython code is [much?] more efficient than PySys_GetObject("modules") calls.

Proposal

In light of all this I recommend that either use of interp->modules be replaced by PySys_GetObject("modules") calls, or the sys module documentation[3] be updated to make clear that sys.modules should not be re-bound (in a CPython implementation detail note).  I'm guessing that the first option is right out.  The documentation addition would be just right.


[1] variables of the interpreter object found by grepping "interp->" in the CPython source:
     modules
     modules_by_index
     next
     codec_search_path
     codec_search_cache
     codec_error_registry
     codecs_initialized
     fscodec_initialized
     modules_reloading
     builtins
     sysdict
     tstate_head
     tscdump
     dlopenflags
[2] see PyImport_GetModuleDict() in Python/import.c
[3] http://docs.python.org/dev/library/sys.html#sys.modules

----------
messages: 141068
nosy: ericsnow, ncoghlan
priority: normal
severity: normal
status: open
title: sys.modules gets special treatment
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12633>
_______________________________________

From report at bugs.python.org  Mon Jul 25 07:15:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Jul 2011 05:15:53 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <E1QlDWC-0002zA-Br@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 198627bbe242 by Ross Lagerwall in branch '3.2':
Issue #12102: Document that buffered files must be flushed before being used
http://hg.python.org/cpython/rev/198627bbe242

New changeset 4898b14dcd69 by Ross Lagerwall in branch 'default':
Issue #12102: Merge with 3.2.
http://hg.python.org/cpython/rev/4898b14dcd69

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Mon Jul 25 07:25:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Jul 2011 05:25:13 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <E1QlDfE-0003e7-NO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e75715f27ce7 by Ross Lagerwall in branch '2.7':
Issue #12102: Document that buffered files must be flushed before being used
http://hg.python.org/cpython/rev/e75715f27ce7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Mon Jul 25 07:26:24 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 25 Jul 2011 05:26:24 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1311571584.25.0.437313489661.issue12102@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Thanks!

----------
assignee:  -> rosslagerwall
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Mon Jul 25 08:25:11 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 25 Jul 2011 06:25:11 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311575111.17.0.69758186886.issue12607@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Attached is a patch which tests all combinations and includes a testcase.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file22747/i12607_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Mon Jul 25 08:36:50 2011
From: report at bugs.python.org (Ashutosh Swain)
Date: Mon, 25 Jul 2011 06:36:50 +0000
Subject: [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>


New submission from Ashutosh Swain <ats.engg at gmail.com>:

URL: http://docs.python.org/tutorial/classes.html
section: 9.4 Random Remarks 

The first sentense is bit confusing:
"Data attributes override method attributes with the same name"

Is it possible to change the sentense something like this:
"Data attributes set through instance override method attributes with the same name"

----------
assignee: docs at python
components: Documentation
messages: 141073
nosy: ats.engg, docs at python
priority: normal
severity: normal
status: open
title: Random Remarks in class documentation
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12634>
_______________________________________

From report at bugs.python.org  Mon Jul 25 09:16:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Jul 2011 07:16:30 +0000
Subject: [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1311578190.95.0.0170099827435.issue12634@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The proposed rewrite doesn't make any sense to me.  Also "set through" is an reads awkwardly.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12634>
_______________________________________

From report at bugs.python.org  Mon Jul 25 09:22:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Jul 2011 07:22:39 +0000
Subject: [issue12633] sys.modules gets special treatment
In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>
Message-ID: <1311578559.54.0.63560602675.issue12633@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

+1 for making this limitation explicit. See the caveat on locals() [1] for an example of how to note this kind of restriction.

[1] http://docs.python.org/dev/library/functions.html#locals

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12633>
_______________________________________

From report at bugs.python.org  Mon Jul 25 09:36:47 2011
From: report at bugs.python.org (HaiYun Yan)
Date: Mon, 25 Jul 2011 07:36:47 +0000
Subject: [issue12635] use "as" for block scope support
In-Reply-To: <1311579407.7.0.367368454098.issue12635@psf.upfronthosting.co.za>
Message-ID: <1311579407.7.0.367368454098.issue12635@psf.upfronthosting.co.za>


New submission from HaiYun Yan <lyricconch at gmail.com>:

use "as" for block scope support
just like mozilla javascript "let" extension
https://developer.mozilla.org/en/new_in_javascript_1.7#Block_scope_with_let_%28Merge_into_let_Statement%29

usage:

as_clause(as_declare): "as" NAME
as_stmt: NAME "as" test
as_expr: "(" expr "as" NAME ")" expr

var declare by as_clause is alive in <suite> only
eg:
<NAME "f" binding saved>with open(...) as f<NAME "f" bind to HEAPObj>:
   ...
<NAME "f" binding restored>

the same rule to "except E as e: "

spec:
from socket import AF_INET as IPv4
<IPv4 bind to socket.AF_INET slot>
IPv4 = None
assert socket.AF_INET == None

var in as_stmt is alive in current indentation
eg:
for i in range(10):
   <NAME "t" binding saved>
   t as f()+1 <NAME "t" bind to f()+1>
   ...
   <NAME "t" binding restored>

var in as_expr is alive in sub expr only
eg:
t = None
x = (2+3 as t) t**2
assert t == None ane  x == 25

Suggestion:
new opcode
ENTER_BLOCK #depth #varslots

----------
components: Interpreter Core
messages: 141076
nosy: lyricconch
priority: normal
severity: normal
status: open
title: use "as" for block scope support
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12635>
_______________________________________

From report at bugs.python.org  Mon Jul 25 11:02:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jul 2011 09:02:48 +0000
Subject: [issue12635] use "as" for block scope support
In-Reply-To: <1311579407.7.0.367368454098.issue12635@psf.upfronthosting.co.za>
Message-ID: <1311584568.3.0.468188314438.issue12635@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

You should propose this to the python-ideas mailing list first.
It might be worth checking the archives of the ML as well -- I think I saw already something similar a while ago.

----------
nosy: +ezio.melotti
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12635>
_______________________________________

From report at bugs.python.org  Mon Jul 25 11:24:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Jul 2011 09:24:02 +0000
Subject: [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1311585842.84.0.744115664332.issue12634@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Indeed that paragraph is not really clear.  I had to read it till the end ("verbs for methods and nouns for data attributes") to figure out what it was talking about.  Even then it's still not clear what it's trying to say.
I *think* it means that if you have a class Foo with a method bar, and you do Foo.bar = 'data', the method will be overridden (so you won't be able to do Foo.bar for the 'data' and Foo.bar() for the method), but the opposite is also true.
Moreover I find both the suggestions for avoiding conflicts (capitalizing method names and/or using an underscore) wrong (both against PEP8).  Also it never happened to me to have an attribute with the same name of a method, and I think in general it's not a common case (becase, as the paragraph says, methods are verbs and attributes nouns).

The whole thing could be rewritten to just say that an attribute name always refers to a single object, either to a method or to some "data".

----------
nosy: +eric.araujo, ezio.melotti, terry.reedy
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12634>
_______________________________________

From report at bugs.python.org  Mon Jul 25 11:44:42 2011
From: report at bugs.python.org (Yaroslav Bulatov)
Date: Mon, 25 Jul 2011 09:44:42 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1311587082.6.0.631686052174.issue9998@psf.upfronthosting.co.za>


Changes by Yaroslav Bulatov <yaroslavvb at gmail.com>:


----------
nosy: +yaroslavvb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Jul 25 11:46:38 2011
From: report at bugs.python.org (Yaroslav Bulatov)
Date: Mon, 25 Jul 2011 09:46:38 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1311587198.14.0.639709696415.issue9998@psf.upfronthosting.co.za>


Yaroslav Bulatov <yaroslavvb at gmail.com> added the comment:

This causes problem for Freetype Python bindings on Linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Jul 25 11:51:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jul 2011 09:51:07 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311587467.81.0.986451643197.issue12607@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

save_fds should be moved outside the try block:

+            try:
+                # save a copy of the standard file descriptors
+                saved_fds = [os.dup(fd) for fd in range(3)]
+                ...
+            finally:
+                for std, saved in enumerate(saved_fds):
+                    os.dup2(saved, std)
+                    os.close(saved)


"temp_fds = [fd for fd, fname in temps]" should also be moved outside its try block.

Why not using .communicate() to write into stdin and read stdout/stderr?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Mon Jul 25 11:52:55 2011
From: report at bugs.python.org (ledave123)
Date: Mon, 25 Jul 2011 09:52:55 +0000
Subject: [issue12636] IDLE ignores -*- coding -*- with -r option
In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>
Message-ID: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>


New submission from ledave123 <ledave123 at yahoo.fr>:

I'm on Windows with cp1252 as the default encoding.
When I use -*- coding: c1252 -*- I get no problems.
When I use -*- coding: utf-8 -*- IDLE -r still opens the file with cp1252 encoding.
Python.exe opens the file with utf-8 correctly.

I think the problem is in Python32\Lib\idlelib\PyShell.py line 585:
In class ModifiedInterpreter:

    def execfile(self, filename, source=None):
        "Execute an existing file"
        if source is None:
            source = open(filename, "r").read() # this is the bug IMHO

----------
components: IDLE
messages: 141081
nosy: ledave123
priority: normal
severity: normal
status: open
title: IDLE ignores -*- coding -*- with -r option
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12636>
_______________________________________

From report at bugs.python.org  Mon Jul 25 11:54:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jul 2011 09:54:39 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311587679.02.0.847156872493.issue12632@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You can use PYTHONIOENCODING="utf-8". Code page 65001 is not exactly like Python UTF-8 codec: see issue #6058.

Using issue #12281, it may be possible to implement a cp65001 codec.

See also issue #1602 for the Windows console.

Why do you use cp65001?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 12:02:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jul 2011 10:02:45 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <1311454495.5.0.801093056111.issue12625@psf.upfronthosting.co.za>
Message-ID: <1311588165.52.0.0926451169654.issue12625@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> getpid() is called after each kill(getpid(), <signum>),
> to "force" the signal delivery

Please write a function (in test.support?) with a comment explaining why you are doing that.

You may also only do this workaround on specific platforms. For example, only on FreeBSD and OpenIndiana (the test would be in the function).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12625>
_______________________________________

From report at bugs.python.org  Mon Jul 25 12:19:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jul 2011 10:19:26 +0000
Subject: [issue10883] urllib: socket is not closed explicitly
In-Reply-To: <1294698764.05.0.403920474459.issue10883@psf.upfronthosting.co.za>
Message-ID: <1311589166.11.0.899718685503.issue10883@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks for your patch. ResourceWarning are really useful!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10883>
_______________________________________

From report at bugs.python.org  Mon Jul 25 13:04:21 2011
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Jul 2011 11:04:21 +0000
Subject: [issue12637] logging lastResort handler not ignoring messages less
	than WARNING
In-Reply-To: <1311591861.64.0.698091326071.issue12637@psf.upfronthosting.co.za>
Message-ID: <1311591861.64.0.698091326071.issue12637@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

The 'Advanced Logging Tutorial' states about the lastResort handler:
"The handler?s level is set to WARNING, so all events at this and
greater severities will be output."

Python 3.2 does not follow this behavior:

Python 3.2 (r32:88445, Jun 18 2011, 20:30:18)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> root = logging.getLogger()
>>> root.setLevel('DEBUG')
>>> root.warning('warning msg')
warning msg
>>> root.debug('debug msg')
debug msg
>>> 

This is fixed with the attached patch:

Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> root = logging.getLogger()
>>> root.setLevel('DEBUG')
>>> root.warning('warning msg')
warning msg
>>> root.debug('debug msg')
>>>

----------
components: Library (Lib)
files: logging_lastResort.patch
keywords: patch
messages: 141085
nosy: xdegaye
priority: normal
severity: normal
status: open
title: logging lastResort handler not ignoring messages less than WARNING
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22748/logging_lastResort.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12637>
_______________________________________

From report at bugs.python.org  Mon Jul 25 13:16:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 11:16:59 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311592619.12.0.00652347590773.issue12463@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch with a test and the proposed fix.

----------
keywords: +needs review, patch
stage:  -> patch review
versions:  -Python 2.6, Python 3.1, Python 3.4
Added file: http://bugs.python.org/file22749/issue12463.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Jul 25 13:21:51 2011
From: report at bugs.python.org (Bruce Ferris)
Date: Mon, 25 Jul 2011 11:21:51 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311592911.66.0.568632142427.issue12632@psf.upfronthosting.co.za>


Bruce Ferris <bferris57 at bferris.co.uk> added the comment:

I use code page 65001 because 1) it displays the UTF-8 characters in my text files with "echo <filename>" on the command line, and 2) that's Microsoft's "official" (whatever that means) code page for UTF-8, and 3) it works in cmd.exe.

Setting aside why I use it, it IS used by some, and Python shouldn't GPF for ANY reason if it can be easily fixed.  Right?

Essentially, 65001 makes Microsoft's console output behave properly (at least with the limited characters in Lucinda Console) so I would think Python should consider not blowing up when it's set.  

To be honest, I just happened to have it set to 65001 to get the output from another program to look right and just happened to run Python to do some quick unrelated calculations.

Imagine my surprise when Python blew, especially when all I did was to run it.  It's not like I asked it to do any UTF-8 or anthing!

Anyway, as far as I understand...  Any GPF is a potential back door.  So, it needs closing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 13:50:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jul 2011 11:50:36 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1311594636.15.0.883172354063.issue12326@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.

----------
title: Linux 3: tests should avoid using sys.platform == 'linux2' -> Linux 3: code should avoid using sys.platform == 'linux2'
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Jul 25 14:02:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jul 2011 12:02:14 +0000
Subject: [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1311595334.65.0.526915065731.issue12634@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have the same reading as Ezio, and the same opinion that it?s unclear and unhelpful.  +1 to saying that there is only one namespace for data attributes and methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12634>
_______________________________________

From report at bugs.python.org  Mon Jul 25 14:37:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Jul 2011 12:37:47 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311597467.68.0.731210455583.issue12632@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In this case it is not a potential security hole, since in fact the "GPF" comes from Python explicitly calling Abort because of a situation it can't handle, as indicated by the error message from Python.  (If it were a true segfault-like error, there would be no message from Python itself.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 15:19:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Jul 2011 13:19:50 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311599990.44.0.595735115627.issue12632@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Python shouldn't GPF for ANY reason if it can be easily fixed

"Code page 65001" issue cannot be "easily" fixed. Did you read the history of the issue #6058? It took one year and a half to decide that cp65001 cannot be set as an alias to UTF-8.

As I wrote, it will be possible to really implement a real cp65001 codec for Python using issue #12281.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 15:56:41 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 25 Jul 2011 13:56:41 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311602201.71.0.784938961409.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I looked into the possibility of retaining newline characters even for files with mixed newlines, but I've decided that's too intrusive an approach. The current implementation specifically takes measures to strip whitespaces from the ends of lines, so it seems outside the scope of this bug to alter that behavior.

So I've taken another stab at a more robust implementation that does newline detection but raises an error if the file contains mixed newlines.

Furthermore, it adds an option (--newline) to specify which newline character to use, bypassing the mixed-newline error and allowing the user to override newline detection.

Here's a demo run:

    PS C:\cpython-issue10639> python .\Tools\scripts\reindent.py .\foo.py
    .\foo.py: mixed newlines detected; cannot continue without --newline
    PS C:\cpython-issue10639> python .\Tools\scripts\reindent.py --newline CRLF .\foo.py
    PS C:\cpython-issue10639> python .\Tools\scripts\reindent.py --newline LF .\foo.py
    PS C:\cpython-issue10639> python .\Tools\scripts\reindent.py .\foo.py

I've published this change as https://bitbucket.org/jaraco/cpython-issue10639/changeset/900df5732f93.

Please review. If this changeset is acceptable, I will push the revisions to the master repo. Please advise if I may also backport to Python 3.2 and 2.7.

----------
hgrepos: +45

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Mon Jul 25 16:17:42 2011
From: report at bugs.python.org (Jonathan Niehof)
Date: Mon, 25 Jul 2011 14:17:42 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1311603462.03.0.57694926138.issue9998@psf.upfronthosting.co.za>


Jonathan Niehof <jniehof at lanl.gov> added the comment:

Yaroslav: does the patch cause problems, or the original issue? If the former, could you be specific so I can try and fix it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Jul 25 17:34:58 2011
From: report at bugs.python.org (Carl)
Date: Mon, 25 Jul 2011 15:34:58 +0000
Subject: [issue12638] urllib.URLopener prematurely deletes files on cleanup
In-Reply-To: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
Message-ID: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>


New submission from Carl <carl at carlbook.com>:

urllib.URLopener (or urllib.request.URLopener for Python 3) and user defined classes that inherit from these prematurely delete files upon cleanup.  Any temporary files downloaded using the .retrieve() method are deleted when an instance of a URLopener is garbage collected.

I feel this is a violation since the filename is returned to the caller and then silently deleted.  It is possible to simply override the .cleanup() method, but I feel this is not a good solution.

----------
components: None
files: bug2.py
messages: 141094
nosy: carlbook
priority: normal
severity: normal
status: open
title: urllib.URLopener prematurely deletes files on cleanup
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22750/bug2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12638>
_______________________________________

From senthil at uthcode.com  Mon Jul 25 17:47:14 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Mon, 25 Jul 2011 23:47:14 +0800
Subject: [issue12638] urllib.URLopener prematurely deletes files on cleanup
In-Reply-To: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
References: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
	<1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
Message-ID: <20110725154714.GA2990@mathmagic>

urlretrieve is a helper function from urllib  module. The way to use
it is:

>>> import urllib.request
>>> urllib.request('http://bugs.python.org')
('/tmp/tmpe873xe', <http.client.HTTPMessage object at 0xb72c2f6c>)
>>> import os
>>> os.stat('/tmp/tmpe873xe')
posix.stat_result(st_mode=33152, st_ino=4462517, st_dev=2054,
st_nlink=1, st_uid=1000, st_gid=1000, st_size=33128,
st_atime=1311608669, st_mtime=1311608670, st_ctime=1311608670)

Works properly for me 3.3 and 2.7. Is there any service that is
running on your machine that deleting the tmp files as soon as they
are created?


From report at bugs.python.org  Mon Jul 25 17:47:23 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 25 Jul 2011 15:47:23 +0000
Subject: [issue12638] urllib.URLopener prematurely deletes files on cleanup
In-Reply-To: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
Message-ID: <20110725154714.GA2990@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

urlretrieve is a helper function from urllib  module. The way to use
it is:

('/tmp/tmpe873xe', <http.client.HTTPMessage object at 0xb72c2f6c>)
>>> import os
>>> os.stat('/tmp/tmpe873xe')
posix.stat_result(st_mode=33152, st_ino=4462517, st_dev=2054,
st_nlink=1, st_uid=1000, st_gid=1000, st_size=33128,
st_atime=1311608669, st_mtime=1311608670, st_ctime=1311608670)

Works properly for me 3.3 and 2.7. Is there any service that is
running on your machine that deleting the tmp files as soon as they
are created?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12638>
_______________________________________

From report at bugs.python.org  Mon Jul 25 17:51:33 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 25 Jul 2011 15:51:33 +0000
Subject: [issue12638] urllib.URLopener prematurely deletes files on cleanup
In-Reply-To: <20110725154714.GA2990@mathmagic>
Message-ID: <20110725155124.GB2990@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

urlretrieve is a helper function from urllib  module. The way to use
it is:

('/tmp/tmpe873xe', <http.client.HTTPMessage object at 0xb72c2f6c>)
>>> import os
>>> os.stat('/tmp/tmpe873xe')

Works!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12638>
_______________________________________

From report at bugs.python.org  Mon Jul 25 17:54:39 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 25 Jul 2011 15:54:39 +0000
Subject: [issue12638] urllib.URLopener prematurely deletes files on cleanup
In-Reply-To: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
Message-ID: <1311609279.0.0.935926971916.issue12638@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Tracker stripped off the code. Here is it.

import urllib.request
urllib.request.urlretrieve('http://bugs.python.org')
('/tmp/tmpe873xe', <http.client.HTTPMessage object at 0xb72c2f6c>)
import os
os.stat('/tmp/tmpe873xe')
posix.stat_result(st_mode=33152, st_ino=4462517, st_dev=2054, st_nlink=1, st_uid=1000, st_gid=1000, st_size=33128, st_atime=1311608669, st_mtime=1311608670, st_ctime=1311608670)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12638>
_______________________________________

From report at bugs.python.org  Mon Jul 25 18:23:27 2011
From: report at bugs.python.org (John Keeping)
Date: Mon, 25 Jul 2011 16:23:27 +0000
Subject: [issue12639] msilib Directory.start_component() fails if keyfile is
	not None
In-Reply-To: <1311611007.28.0.321431208072.issue12639@psf.upfronthosting.co.za>
Message-ID: <1311611007.28.0.321431208072.issue12639@psf.upfronthosting.co.za>


New submission from John Keeping <john.keeping at lineone.net>:

If msilib.Directory.start_component() is called with the keyfile argument not None then it attempts to call self.cab.gen_id(self.absolute, keyfile) but the msilib.CAB.gen_id() method takes only two arguments (not three).

----------
components: Windows
files: msilib.gen_id.patch
keywords: patch
messages: 141098
nosy: john.keeping
priority: normal
severity: normal
status: open
title: msilib Directory.start_component() fails if keyfile is not None
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22751/msilib.gen_id.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12639>
_______________________________________

From report at bugs.python.org  Mon Jul 25 18:36:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Jul 2011 16:36:16 +0000
Subject: [issue11784] multiprocessing.Process.join: timeout argument doesn't
	specify time unit.
In-Reply-To: <1302102892.38.0.716462659094.issue11784@psf.upfronthosting.co.za>
Message-ID: <E1QlO8c-00034h-TM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8d67fd820627 by Charles-Fran?ois Natali in branch 'default':
Issue #11784: Improve multiprocessing.Process.join() documentation. Patch by
http://hg.python.org/cpython/rev/8d67fd820627

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11784>
_______________________________________

From report at bugs.python.org  Mon Jul 25 18:38:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 25 Jul 2011 16:38:16 +0000
Subject: [issue11784] multiprocessing.Process.join: timeout argument doesn't
	specify time unit.
In-Reply-To: <1302102892.38.0.716462659094.issue11784@psf.upfronthosting.co.za>
Message-ID: <1311611896.17.0.0585320217077.issue11784@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed to default.
Patrick, thanks for the patch!

----------
nosy: +neologix
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/issue11784>
_______________________________________

From report at bugs.python.org  Mon Jul 25 18:46:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 25 Jul 2011 16:46:43 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <1311588165.52.0.0926451169654.issue12625@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0PJG5ysovC+ESQcBWedDYu3t-eYadUj8J33M6yijs3Wg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Please write a function (in test.support?) with a comment explaining why you
> are doing that.
> You may also only do this workaround on specific platforms. For example,
> only on FreeBSD and OpenIndiana (the test would be in the function).

There's already a comment right before the first call to getpid(). I
thought about making it a function, but since it's such a kludge, it
dropped the idea. I don't mind making it a function, though.
As for calling this only on specific platforms, well, I don't know
exactly which platforms are affected, so I stayed on the safe side
(for example, is FreeBSD4 affected?).

But I'd like first to make sure this works. IIRC, you have access to a
FreeBSD6 box. Could you test it there and see if it works?

I promise, I'll soon setup a clone to be able to test my patches on
the buildbot. I just have to select "Server-side clone" on
http://hg.python.org/cpython/# ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12625>
_______________________________________

From report at bugs.python.org  Mon Jul 25 18:57:51 2011
From: report at bugs.python.org (Carl)
Date: Mon, 25 Jul 2011 16:57:51 +0000
Subject: [issue12638] urllib.URLopener prematurely deletes files on cleanup
In-Reply-To: <1311608098.49.0.512505187556.issue12638@psf.upfronthosting.co.za>
Message-ID: <1311613071.0.0.339822180775.issue12638@psf.upfronthosting.co.za>


Carl <carl at carlbook.com> added the comment:

@orsenthil, that is the correct behavior if you do not want to override any of URLopener's handlers for error codes.  In my case, I wanted to override FancyURLopener (a child class of URLopener) to override HTTP 401 behavior.  Using urlretrieve is not correct in this case.

Also included python 3.2 code, I didn't test 3.1.

----------
Added file: http://bugs.python.org/file22752/bug3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12638>
_______________________________________

From report at bugs.python.org  Mon Jul 25 19:10:37 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Jul 2011 17:10:37 +0000
Subject: [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1311613837.34.0.0185530896514.issue12634@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

That sentence is wrong to imply that there is anything special about data versus method attributes with respect to overriding -- or that attributes are special when it comes to names in a single namespace. What I think the paragraph should say, if not just deleted, is something like.

"Instance attributes hide class attributes. Instance data names are often intended to override class data names. But instance data names masking methods names is likely a mistake. This can be avoided by using verbs for method names and nouns for data names."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12634>
_______________________________________

From report at bugs.python.org  Mon Jul 25 19:14:51 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 25 Jul 2011 17:14:51 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311614091.81.0.940228721064.issue12463@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Yes, this is what I want. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Jul 25 19:35:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 25 Jul 2011 17:35:44 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311615344.18.0.2489921184.issue12463@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Seems reasonable to me.
What bothers me is this comment in shutdown's docstring:

        """Stops the serve_forever loop.

        Blocks until the loop has finished. This must be called while
        serve_forever() is running in another thread, or it will
        deadlock.
        """

I'm adding Giampaolo to the nosy list, to get his input on this.

----------
nosy: +giampaolo.rodola, neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Jul 25 19:38:03 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 25 Jul 2011 17:38:03 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1311615483.28.0.386935970652.issue6477@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've encountered a use-case where the need to pickle NoneType is more relevant (and difficult to work around).

We have a strongly-type Limited Python language, LimPy, which is based on Python (https://bitbucket.org/yougov/limpy). This parser takes, as part of its initialization arguments, a type specification (indicating which types are allowed and not allowed). In some cases, the return value may be `None`, in which case the specification says the type must be `NoneType`.

We're attempting to run this parser in a separate process, using the multiprocessing module, which requires that the arguments passed to and from the parser be pickleable. Unfortunately, because `NoneType` is in the type specification, it cannot be passed to the parser.

Here's an example of one such type specification (from the test suite):

    class SomeFunctionNamespace:
        @signature([IListType], [], None, ListOfInt)
        def listcount(self, l):
            return range(len(l))

        @signature([IListType], [], None, int)
        def listlen(self, l):
            return len(l)

        # ...

        @signature([IIntType], [IStringType], IStringType, NoneType)
        def givespec(self, *args):
            for a in args:
                print a


Note that we can pickle `str` and `int` just fine. Only type(None) fails.

It would be possible to re-write the entire LimPy system (and its child projects) to use a different object where currently NoneType is used, though NoneType is precisely the right thing to be used here except that it can't be pickled.

Since type(None) is a fundamental Python type, it strikes me as a bug that it's not pickleable, though I concede that it's also reasonable to interpret this issue as a feature request (as it's never been pickleable).

Nick makes some good comments that pickling of NoneType should be done right, but other than that, there haven't been any reasons why in principle NoneType should not be pickleable.

NoneType is more akin to `str` and `int` which are pickleable than it is to a function or type(NotImplemented), and this is evident by the way that LimPy uses it (before there was any consideration for pickleability).

Therefore, I propose we reconsider that NoneType should be made pickleable.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6477>
_______________________________________

From report at bugs.python.org  Mon Jul 25 19:50:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 25 Jul 2011 17:50:15 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1311616215.76.0.312432077075.issue6419@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Stephan, did you apply the patch?

I think the failures you were experiencing on amd64 could be due to issue #12181: OpenBSD's struct kevent definition differs from FreeBSD/NetBSD, which can trigger a segfault on sparc64 (which doesn't allow unaligned access).

By the way, Henry, would you be interested in writting a patch for issue #12181?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Mon Jul 25 19:58:20 2011
From: report at bugs.python.org (Bruce Ferris)
Date: Mon, 25 Jul 2011 17:58:20 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311616700.19.0.876359151528.issue12632@psf.upfronthosting.co.za>


Bruce Ferris <bferris57 at bferris.co.uk> added the comment:

I disagree with the "it's not really a GPF since it calls Abort".

Consider the following cmd.exe session...

  Microsoft Windows [Version 6.0.6002]
  Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

  D:\>chcp 65001
  Active code page: 65001

  D:\>python >t.txt
  Fatal Python error: Py_Initialize: can't initialize sys standard streams
  LookupError: unknown encoding: cp65001

  This application has requested the Runtime to terminate it in an unusual way.
  Please contact the application's support team for more information.

  D:\>type t.txt

  D:\>dir t.txt
  Volume in drive D is DATA
  Volume Serial Number is 2E61-626C

  Directory of D:\

  25/07/2011  06:10 PM                 0 t.txt
                 1 File(s)              0 bytes
                 0 Dir(s)  16,768,655,360 bytes free

  D:\>

This means that, even if it was "intentional", from a programatic point of view. the Python process in this case leaves no other indication other than transient bytes in the transient cmd.exe console buffer.  No way of redirecting the output and examining it.

I strongly disagree with the statement "(If it were a true segfault-like error, there would be no message from Python itself.)"

The "no message from Python itself" case is shown above.

My application handles code page 65001 just fine, no problems.  If it attempts to use Windows WriteConsole function and it fails, it tries using WriteFile instead.  So, when my application fails and output is redirected, it produces output.

But, Python 3.1 doesn't.  See the following Microsoft MSDN link, it states the WriteConsole point explicitly...

  http://msdn.microsoft.com/en-us/library/ms687401%28v=VS.85%29.aspx

So, if Python doesn't like Code Page 65001, for whatever reason, it can simply save it on startup, and change it to whatever makes it happy.  Then, upon Python exit (including Abort), change it back to 65001 before calling Abort.

I'm sorry, but the following is "easy" in my book...

  1) At Startup...  Call GetConsoleOutputCP and save that somewhere.

                    If code page is 65001, change it to something that
                    doesn't cause problems by calling SetConsoleOutputCP

  2) On Write... If WriteConsole fails, try calling WriteFile instead.

  3) At Abort or Exit... Call SetConsoleOutputCP to set it back
                         to whatever it was on Startup.

I don't care if your app (Python) can display UTF-8 on Microsoft's cmd.exe console or if it can't. 

All I'm trying to do is point out a bit of misbehaviour that CAN be easily changed and will make your product more resilient.

I don't know the details of how Python deals with character encoding and, quite honestly, I shouldn't need to since it's not my product.  however, I DO know how I handle a similiar scenario in my own app.

Microsoft made it complicated, not me.  But, I can "easily" get around the problem using the above scenario.  If Python can't do it just as "easily", then it tells me more about Python's implementation and the people behind Python then it tells me about Microsoft and the people behind Windows.

Don't get me wrong, I love Python as a tool for solving certain classes of problems and, please, keep up the good work.  It's appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 20:17:39 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 18:17:39 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311617859.69.0.586416083012.issue12463@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

OK, so this is intentional. But why? Why does it *have to* block on every call? It would be more reasonable to make in not block if serve_forever() is not running and for example add a function to check whether serve_forever() is running or not.

If for some reason it has to fail when serve_forever() is not running, a deadlock is still not good. An exception would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Jul 25 20:19:58 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Mon, 25 Jul 2011 18:19:58 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311617998.24.0.921872241064.issue12614@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
hgrepos: +46
Added file: http://bugs.python.org/file22753/request-method.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Mon Jul 25 20:37:01 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Jul 2011 18:37:01 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311619021.94.0.358531146514.issue12463@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

IMHO, both methods should raise an exception (RuntimeError maybe) in case the server is already started or stopped, at least in Python 3.3, while previous python versions should silently "pass".

It also makes sense to add a "running" property returning a bool, as suggested by Petri.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Jul 25 20:50:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Jul 2011 18:50:32 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311619832.57.0.999699671922.issue12632@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you read what I wrote, I did not say that it wasn't a GPF.  I said that an Abort is different from writing into or reading from memory incorrectly (which is what leads to security holes).

We don't have many Windows developers active enough to have gotten commit privileges, but perhaps one of them will be have time enough to take a look at your suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Mon Jul 25 20:54:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 18:54:21 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1311620061.02.0.248707220464.issue12464@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch that fixes the issue and adds a test case for it.

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file22754/issue12464.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Mon Jul 25 20:58:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Jul 2011 18:58:21 +0000
Subject: [issue12637] logging lastResort handler not ignoring messages less
	than WARNING
In-Reply-To: <1311591861.64.0.698091326071.issue12637@psf.upfronthosting.co.za>
Message-ID: <E1QlQM8-0007y3-0M@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d11a1a373f58 by Vinay Sajip in branch '3.2':
Fixes #12637: Last resort messages now correctly handled. Thanks to Xavier de Gaye for the patch."
http://hg.python.org/cpython/rev/d11a1a373f58

New changeset de13ce98ca3b by Vinay Sajip in branch 'default':
Fixes #12637: Merged fix from 3.2 and added test.
http://hg.python.org/cpython/rev/de13ce98ca3b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12637>
_______________________________________

From report at bugs.python.org  Mon Jul 25 20:58:54 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 18:58:54 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1311620334.96.0.595459775235.issue12464@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Adding potential reviewers to nosy list.

----------
nosy: +georg.brandl, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:00:40 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 25 Jul 2011 19:00:40 +0000
Subject: [issue12637] logging lastResort handler not ignoring messages less
	than WARNING
In-Reply-To: <1311591861.64.0.698091326071.issue12637@psf.upfronthosting.co.za>
Message-ID: <1311620440.98.0.359133443217.issue12637@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
resolution:  -> fixed
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12637>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:01:27 2011
From: report at bugs.python.org (Yaroslav Bulatov)
Date: Mon, 25 Jul 2011 19:01:27 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1311620487.29.0.64279527433.issue9998@psf.upfronthosting.co.za>


Yaroslav Bulatov <yaroslavvb at gmail.com> added the comment:

Sorry for confusion, I meant the original problem causes problems. I haven't tested the patch because my target machines don't have gcc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:02:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 19:02:21 +0000
Subject: [issue12439] BaseHTTPServer's send_reponse adds extra "\r\n" when
	using HTTPMessage in input
In-Reply-To: <1309340125.43.0.831188381846.issue12439@psf.upfronthosting.co.za>
Message-ID: <1311620541.84.0.996797501173.issue12439@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12439>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:14:30 2011
From: report at bugs.python.org (Aaron Meurer)
Date: Mon, 25 Jul 2011 19:14:30 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1311621270.84.0.492930690566.issue12611@psf.upfronthosting.co.za>


Changes by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +Aaron.Meurer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12611>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:38:17 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Jul 2011 19:38:17 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311622697.35.0.26787539251.issue12463@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment (tests still missing).

----------
Added file: http://bugs.python.org/file22755/socketserver.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:48:01 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Jul 2011 19:48:01 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1311623281.07.0.0325743453173.issue6419@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

No, I didn't commit it. Currently I don't have an amd64 OpenBSD install to do further testing.

The problem could be #12181, it could also be qemu, which sometimes has
issues with OpenBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:50:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 19:50:15 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311623415.39.0.733166391662.issue12380@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> The solution could be global, to allow bytearray fit the 'c' format of
> PyArg_ParseTuple. Then one would also be able to pass a bytearray into
> other stringlib methods requiring the 'c' format.

Another possibility would be the change the 'c' format so that it accepts any object that supports the buffer protocol and whose buffer length is 1.

Attaching two patches: The first allows bytes and bytearray, the second allows any object that supports the buffer protocol.

----------
keywords: +patch
Added file: http://bugs.python.org/file22756/c_format_bytearray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:50:45 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 19:50:45 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311623445.15.0.0203895614293.issue12380@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Added file: http://bugs.python.org/file22757/c_format_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:51:05 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 25 Jul 2011 19:51:05 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311623465.26.0.933174308613.issue12380@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:53:25 2011
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 25 Jul 2011 19:53:25 +0000
Subject: [issue12547] whatsnew/3.3: error in example about nntplib
In-Reply-To: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>
Message-ID: <1311623605.75.0.266239424894.issue12547@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

The very same example (with the same error) can be found in
Doc/library/nntplib.rst

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file22758/library.nntplib.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12547>
_______________________________________

From report at bugs.python.org  Mon Jul 25 21:55:18 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Jul 2011 19:55:18 +0000
Subject: [issue12560] libpython.so not built on OpenBSD
In-Reply-To: <1310662692.29.0.747944730785.issue12560@psf.upfronthosting.co.za>
Message-ID: <1311623718.7.0.943094902455.issue12560@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

For the record: The other failures I mentioned were almost certainly
OpenBSD 4.5 / autoconf specific, so I didn't bother. Cairo has a
workaround, but I think that goes too far.

http://cairo.sourcearchive.com/documentation/1.9.4/cairo-atomic-private_8h-source.html

/* The autoconf on OpenBSD 4.5 produces the malformed constant name
 * SIZEOF_VOID__ rather than SIZEOF_VOID_P.  Work around that here. */
#if !defined(SIZEOF_VOID_P) && defined(SIZEOF_VOID__)
# define SIZEOF_VOID_P SIZEOF_VOID__
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12560>
_______________________________________

From report at bugs.python.org  Mon Jul 25 22:27:17 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 25 Jul 2011 20:27:17 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <CAH_1eM24Y0ADauNB2EJXYw32_g_QpBnC-q-CS7S5oUfY2oym5w@mail.gmail.com>
Message-ID: <20110725202706.GA35353@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> Are you willing to update your patch accordingly?

I'm a vain rooster!  I've used fullfsync() in 11877-standalone.1.diff!
Sorry for that, haypo.  :-/

11877.fullsync-1.diff uses fullsync() and will instead always be
provided when fsync() is available, to which it will fall back if
no special operating system functionality is available.

I really think this is the cleanest solution, because like this
a user can state "i want the strongest guarantees available on
data integrity", and Python does just that.

--Steffen
Ciao, sdaoden(*)(gmail.com)
ASCII ribbon campaign           ( ) More nuclear fission plants
  against HTML e-mail            X    can serve more coloured
    and proprietary attachments / \     and sounding animations

----------
Added file: http://bugs.python.org/file22759/11877.fullsync-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -706,6 +706,31 @@
    Availability: Unix, and Windows starting in 2.2.3.
 
 
+.. function:: fullsync(fd)
+
+   The POSIX standart requires that :c:func:`fsync` must transfer the buffered
+   data to the storage device, not that the data is actually written by the
+   device itself.  It explicitely leaves it up to operating system implementors
+   whether users are given stronger guarantees on data integrity or not.  Some
+   systems also offer special functions which overtake the part of making such
+   stronger guarantees, i.e., Mac OS X and NetBSD.  :func:`fullsync` is
+   identical to :func:`fsync` unless there is such special functionality
+   available, in which case that will be used.
+   To strive for best-possible data integrity, the following can be done::
+
+      # Force writeout of local buffer modifications
+      f.flush()
+      # Then synchronize the changes to physical backing store
+      if hasattr(os, 'fsync'):
+         os.fullsync(f.fileno())
+
+   ..note::
+      Calling this function may take a long time, since it may block
+      until the disk reports that the transfer has been completed.
+
+   Availability: See :func:`fsync`.
+
+
 .. function:: ftruncate(fd, length)
 
    Truncate the file corresponding to file descriptor *fd*, so that it is at most
diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py
--- a/Lib/test/test_os.py
+++ b/Lib/test/test_os.py
@@ -554,7 +554,7 @@
 
 class TestInvalidFD(unittest.TestCase):
     singles = ["fchdir", "fdopen", "dup", "fdatasync", "fstat",
-               "fstatvfs", "fsync", "tcgetpgrp", "ttyname"]
+               "fstatvfs", "fsync", "fullsync", "tcgetpgrp", "ttyname"]
     #singles.append("close")
     #We omit close because it doesn'r raise an exception on some platforms
     def get_single(f):
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -1855,6 +1855,42 @@
 {
     return posix_fildes(fdobj, fsync);
 }
+
+PyDoc_STRVAR(fullsync__doc__,
+"fullsync(fd)\n\n"
+"force write of file buffers to disk, and the flush of disk caches\n"
+"of the file given by file descriptor fd.");
+
+static PyObject *
+fullsync(PyObject *self, PyObject *fdobj)
+{
+    /* See issue 11877 discussion */
+    int res, fd = PyObject_AsFileDescriptor(fdobj);
+    if (fd < 0)
+        return NULL;
+    if (!_PyVerify_fd(fd))
+        return posix_error();
+
+    Py_BEGIN_ALLOW_THREADS
+# if defined __APPLE__
+    /* F_FULLFSYNC is not supported for all types of FDs/FSYSs;
+     * be on the safe side and test for inappropriate ioctl errors.
+     * Because plain fsync() may succeed even then, let it decide about error */
+    res = fcntl(fd, F_FULLFSYNC);
+    if (res < 0 && errno == ENOTTY)
+        res = fsync(fd);
+# elif defined __NetBSD__
+    res = fsync_range(fd, FFILESYNC | FDISKSYNC, 0, 0);
+# else
+    res = fsync(fd);
+# endif
+    Py_END_ALLOW_THREADS
+
+    if (res < 0)
+        return posix_error();
+    Py_INCREF(Py_None);
+    return Py_None;
+}
 #endif /* HAVE_FSYNC */
 
 #ifdef HAVE_FDATASYNC
@@ -8953,6 +8989,7 @@
 #endif
 #ifdef HAVE_FSYNC
     {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fullsync",    fullsync, METH_O, fullsync__doc__},
 #endif
 #ifdef HAVE_FDATASYNC
     {"fdatasync",   posix_fdatasync,  METH_O, posix_fdatasync__doc__},

From report at bugs.python.org  Mon Jul 25 22:30:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 25 Jul 2011 20:30:11 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1311625811.35.0.0551055814689.issue12464@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm not sure I see what the problem is:
- if the idea behind this is the risk of symlink attack (like issue #4489), it's not the case here, because the directory is created with 0600 permission
- furthermore, the attached patch has a TOCTTOU race, between the the call to os.path.islink() and the call to rmtree()

So I'd like to know the problem we're trying to solve here.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Mon Jul 25 22:36:58 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 25 Jul 2011 20:36:58 +0000
Subject: [issue12633] sys.modules doc entry should reflect restrictions
In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>
Message-ID: <1311626218.69.0.212688212691.issue12633@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Would an implementation detail note be inappropriate here?  I only ask because it looks like the imp module's use of interp->modules is implementation specific.

Here's a patch for Doc/library/sys.rst that adds the note.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +patch
nosy: +docs at python
title: sys.modules gets special treatment -> sys.modules doc entry should reflect restrictions
Added file: http://bugs.python.org/file22760/sys_modules_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12633>
_______________________________________

From report at bugs.python.org  Mon Jul 25 22:43:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 25 Jul 2011 20:43:31 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
	failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1311626611.98.0.080557357759.issue11871@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The attached patch bumps the barrier's default timeout to 300ms: it should be more than enough (unless you got a really crappy scheduler, or a really heavily loaded machine), especially since this problem doesn't seem to occur often (AFAICT).

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file22761/test_barrier_timeout.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11871>
_______________________________________

From report at bugs.python.org  Mon Jul 25 23:48:54 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Jul 2011 21:48:54 +0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1311630534.1.0.7516729008.issue1641@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This patch is now available as a recipe for python 2.x:
http://code.activestate.com/recipes/577808-asyncore-scheduler/

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
_______________________________________

From report at bugs.python.org  Tue Jul 26 00:43:11 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Jul 2011 22:43:11 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311633791.1.0.767533843944.issue12463@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

New patch including tests.

----------
Added file: http://bugs.python.org/file22762/socketserver.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:06:18 2011
From: report at bugs.python.org (Aaron Meurer)
Date: Mon, 25 Jul 2011 23:06:18 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1311635178.71.0.613660339973.issue12613@psf.upfronthosting.co.za>


Changes by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +Aaron.Meurer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12613>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:06:40 2011
From: report at bugs.python.org (Aaron Meurer)
Date: Mon, 25 Jul 2011 23:06:40 +0000
Subject: [issue12616] zip fixer fails on zip()[:-1]
In-Reply-To: <1311372700.75.0.0919550613362.issue12616@psf.upfronthosting.co.za>
Message-ID: <1311635200.93.0.10158714382.issue12616@psf.upfronthosting.co.za>


Changes by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +Aaron.Meurer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12616>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:07:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Jul 2011 23:07:34 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311635254.16.0.0347994499335.issue12463@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you explain the issue a bit more?
If thread A calls shutdown(), and thread B calls serve_forever() a bit later, thread A should IMO wait for serve_forever() to finish.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:10:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Jul 2011 23:10:06 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311635406.16.0.905091676123.issue12380@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

c_format_bytearray.patch looks ok to me. The other proposal is too broad, and may lead to confusing behaviour.
In any case, some tests are needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:17:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Jul 2011 23:17:40 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1311635860.86.0.653325461046.issue12464@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Without even mentioning the possibility attacks, I think it's wrong for the cleanup routine to follow symbolic links. It should instead simply remove the links, and not mess with anything outside of the temporary directory.

Note that shutil.rmtree() does the right thing by calling lstat(). TemporaryDirectory interestingly uses a "stripped down version of rmtree" which doesn't retain that subtlety.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:22:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Jul 2011 23:22:00 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1311636120.86.0.393513277597.issue6419@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +haypo
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:34:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Jul 2011 23:34:00 +0000
Subject: [issue12231] regrtest: add -k and -K options to filter tests by
	function/file names
In-Reply-To: <1306886173.49.0.536773734975.issue12231@psf.upfronthosting.co.za>
Message-ID: <1311636840.04.0.579572306908.issue12231@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch doesn't work if run_unittest() is called with an already constructed test suite or test case (the patch in #12626 does).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12231>
_______________________________________

From report at bugs.python.org  Tue Jul 26 01:37:51 2011
From: report at bugs.python.org (python272)
Date: Mon, 25 Jul 2011 23:37:51 +0000
Subject: [issue12640] test_ctypes seg fault (test_callback_register_double);
	armv7; gcc 4.5.1
In-Reply-To: <1311637071.74.0.758300374846.issue12640@psf.upfronthosting.co.za>
Message-ID: <1311637071.74.0.758300374846.issue12640@psf.upfronthosting.co.za>


New submission from python272 <letters.random13 at gmail.com>:

[meego]$/opt/org.python.python-2.7.2/bin/python -m test.regrtest ...
...
test_callback_register_double (ctypes.test.test_callbacks.SampleCallbacksTestCase) ... Segmentation fault

this is after a native (not cross-compile) configure; make; make install on armv7:
== CPython 2.7.2 (default, Jul 25 2011, 11:06:06) [GCC 4.5.1 20100731 (MeeGo 4.5.1-1) [release 4.5-2010.09-1]]
==   Linux-2.6.37-24.5.CE-adaptation-n900-armv7l-with-glibc2.4 little-endian
==   /tmp/test_python_6700
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0)

that is the only regrtest seg fault, but there are several worrisome(?) failures in test_ctypes:
...
======================================================================
FAIL: test_longlongresult (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/org.python.python-2.7.2/lib/python2.7/ctypes/test/test_functions.py", line 167, in test_longlongresult
    self.assertEqual(result, 21)
AssertionError: 10L != 21
...
Ran 335 tests in 3.949s

FAILED (failures=17, errors=1, skipped=1)
test test_ctypes failed -- multiple errors occurred
1 test failed:
    test_ctypes
============

a few other test modules have failures, they appear to be less severe:
test_cmath 
test_float 
#http://bugs.python.org/issue12331
test_lib2to3 
test_math 
test_pyexpat 
test_strtod


=================
note: the arm systems i have access to (meego armv7 & android sl4a/py4a) both natively use python < 2.6.7; forgive my ignorance if 2.7 series is not expected to be mature on arm. please also forgive if i should have just disabled ctypes in setup.py as many of the online (cross-compile) instructions suggest:
disabled_module_list.append('_ctypes')
===============

test_ctypes for a native build of 2.6.7 does not seg fault, but does have the same test failures:
========
...
Ran 327 tests in 3.025s

FAILED (failures=17)
test test_ctypes failed -- multiple errors occurred
1 test failed:
    test_ctypes

----------
components: Tests
messages: 141131
nosy: python272
priority: normal
severity: normal
status: open
title: test_ctypes seg fault (test_callback_register_double); armv7; gcc 4.5.1
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12640>
_______________________________________

From report at bugs.python.org  Tue Jul 26 02:42:41 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Jul 2011 00:42:41 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1311400060.11.0.533131855752.issue11049@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7UzyZT69guJDTKihDmeBa5m6vuMAJRmmbKTqxUeucF9w@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Jul 22, 2011 at 22:47, Eli Bendersky <report at bugs.python.org> wrote:

>
> Eli Bendersky <eliben at gmail.com> added the comment:
>
> Brett, what do you mean by "listed as an essential test in regrtest". The
> regrtest.STDTESTS list?
>

Yes

----------
Added file: http://bugs.python.org/file22763/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Fri, Jul 22, 2011 at 22:47, Eli Bendersky <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>
Eli Bendersky &lt;<a href="mailto:eliben at gmail.com">eliben at gmail.com</a>&gt; added the comment:<br>
<br>
</div>Brett, what do you mean by &quot;listed as an essential test in regrtest&quot;. The regrtest.STDTESTS list?<br></blockquote><div><br>Yes <br></div></div>

From report at bugs.python.org  Tue Jul 26 02:43:56 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 26 Jul 2011 00:43:56 +0000
Subject: [issue12615] add array.zeroes
In-Reply-To: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>
Message-ID: <1311641036.95.0.209048714772.issue12615@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Compare however the behaviour of bytes() and bytearray() which support direct zero initialisation of a region of memory by passing an integer to their constructor.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12615>
_______________________________________

From report at bugs.python.org  Tue Jul 26 03:44:54 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 26 Jul 2011 01:44:54 +0000
Subject: [issue12615] add array.zeroes
In-Reply-To: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>
Message-ID: <1311644694.55.0.61518436726.issue12615@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12615>
_______________________________________

From report at bugs.python.org  Tue Jul 26 03:56:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 26 Jul 2011 01:56:08 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1311645368.86.0.968101308186.issue12464@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I agree with Antoine - it's a simple bug introduced by the attempt to allow temporary directories to be correctly cleaned up during interpreter shutdown.

The race condition due to the usage of LBYL is shared with the full shutil.rmtree implementation, so the patch looks reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Tue Jul 26 06:44:20 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 26 Jul 2011 04:44:20 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311655460.29.0.137054061309.issue12607@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

communicate() requires setting stdin, stdout and stderr to subprocess.PIPE which defeats the purpose of the test: setting them to 0, 1 and 2 (in various orders) so that they need to be swapped...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Tue Jul 26 08:38:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jul 2011 06:38:12 +0000
Subject: [issue12547] whatsnew/3.3: error in example about nntplib
In-Reply-To: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>
Message-ID: <E1QlbHO-0004JL-KH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 95c34bce986c by Ezio Melotti in branch 'default':
#12547: Fix example in nntplib doc. Patch by July Tikhonov.
http://hg.python.org/cpython/rev/95c34bce986c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12547>
_______________________________________

From report at bugs.python.org  Tue Jul 26 08:38:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jul 2011 06:38:58 +0000
Subject: [issue12547] whatsnew/3.3: error in example about nntplib
In-Reply-To: <1310544811.28.0.517615627121.issue12547@psf.upfronthosting.co.za>
Message-ID: <1311662338.56.0.573011504571.issue12547@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks again for the patch!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12547>
_______________________________________

From report at bugs.python.org  Tue Jul 26 09:45:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 26 Jul 2011 07:45:11 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1311645368.86.0.968101308186.issue12464@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3SmAR8DisytwCgVa-3Pocczv7n=0y+vsBAX9e9yt9LwQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I agree with Antoine - it's a simple bug

Alright, in that case I agree (I thought this was considered as a
security issue).

Two comments on the patch:

Lib/tempfile.py:
 # Don't recurse to symlinked directories (issue #12464)

Is it really necessary to indicate the issue reference here (there's
already version control, no need to tag the code itself)? It does make
sense in the test, though.

Lib/test/test_tempfile.py:
def test_cleanup_with_symlink_to_a_directory(self):
    # cleanup() should not follow symlinks to directories (issue #12464)
    [...]
    # Symlink d1/foo -> d2
    os.symlink(d2.name, os.path.join(d1.name, "foo"))

Does Windows have symlinks?
Looking at Modules/posixmodule.c, I'm not sure, and there seems to be
a version of os.symlink() that takes an argument indicating whether
the target is a directory or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Tue Jul 26 12:23:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jul 2011 10:23:04 +0000
Subject: [issue12615] add array.zeroes
In-Reply-To: <1311359712.07.0.0731829142816.issue12615@psf.upfronthosting.co.za>
Message-ID: <1311675784.48.0.163728591168.issue12615@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Array has been around for a very long time and this functionality has never been requested.  That and the fact that we already have a way to do it (the same way as for lists) is a strong indication that this isn't needed at all.

----------
resolution:  -> rejected
status: open -> closed
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12615>
_______________________________________

From report at bugs.python.org  Tue Jul 26 12:26:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 Jul 2011 10:26:28 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311675988.87.0.980715982616.issue12632@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

First, a call to abort() is not a GPF: it's not an interrupt from the kernel or the OS, it's just an explicit (albeit brutal) way to exit from an application.  There is no potential back door here.

Then, the "Fatal Python error:" line is written to stderr. It's possible to redirect it (try with "python 2>t.txt").
The message "This application..." is written by the Microsoft C Runtime Library, I don't know if it is also printed to stderr.

Furthermore, in this case the application will have a particular exit code, IIRC it's 3; from the cmd.exe you can get it with "echo %ERRORLEVEL%".  Normally python processes exit with a status of 0 (everything is OK) or 1 (if an exception is raised and not caught)

Finally, the "fix" you suggest would be applicable if python used WriteConsole or WriteFile... but it does not!  It uses the write() function, which probably calls WriteConsole or WriteFile at some point, but does not take unicode characters...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Tue Jul 26 12:28:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jul 2011 10:28:44 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311676124.5.0.0423397313784.issue12632@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Finally, the "fix" you suggest would be applicable if python
> used WriteConsole or WriteFile... but it does not!  It uses
> the write() function, which probably calls WriteConsole 
> or WriteFile at some point, but does not take unicode characters...

The issue #1602 discuss how to change Python to use WriteConsole.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Tue Jul 26 12:31:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 26 Jul 2011 10:31:59 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <CAH_1eM3SmAR8DisytwCgVa-3Pocczv7n=0y+vsBAX9e9yt9LwQ@mail.gmail.com>
Message-ID: <20110726103155.GA2095@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

Charles-Fran?ois Natali wrote:
> > I agree with Antoine - it's a simple bug
> 
> Alright, in that case I agree (I thought this was considered as a
> security issue).

Yes. The problem is that cleanup() does not delete the temporary
directory but deletes files in the linked directory, even if it's
outside the temporary directory.

> Two comments on the patch:
> 
> Lib/tempfile.py:
>  # Don't recurse to symlinked directories (issue #12464)
> 
> Is it really necessary to indicate the issue reference here (there's
> already version control, no need to tag the code itself)? It does make
> sense in the test, though.

True.

> Lib/test/test_tempfile.py:
> def test_cleanup_with_symlink_to_a_directory(self):
>     # cleanup() should not follow symlinks to directories (issue #12464)
>     [...]
>     # Symlink d1/foo -> d2
>     os.symlink(d2.name, os.path.join(d1.name, "foo"))
> 
> Does Windows have symlinks?
> Looking at Modules/posixmodule.c, I'm not sure, and there seems to be
> a version of os.symlink() that takes an argument indicating whether
> the target is a directory or not.

According to the documentation of os.symlink(), symlinks are available
on Windows 6.0 (Vista) and later, so the test should check for this.
I'm not sure how this can be done, though, as there's no
requires_windows_version() decorator in test.support.

The documentation also says that the extra parameter of os.symlink()
only has an effect it the symlink target does not exist when the link
is created. In the test it does, so I think os.link() and os.symlink()
should both work correctly, also on Windows.

If someone suggests how to test for the Windows version, I'll update
the patch, also to remove the issue reference from the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:24:32 2011
From: report at bugs.python.org (Karl Johan Kleist)
Date: Tue, 26 Jul 2011 11:24:32 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1311679472.58.0.132696587761.issue3581@psf.upfronthosting.co.za>


Karl Johan Kleist <karl.johan at kleist-it-consulting.de> added the comment:

If it could be of interest to anybody:

When running "make test" after building Python 2.7.2, I get the error message "1 test failed: test_uuid".

> uname -a
Linux h1488277 2.6.18-028stab091.2 #1 SMP Fri Jun 3 00:02:40 MSD 2011 i686 athlon i386 GNU/Linux

This is a "virtual root server" (http://www.strato.de/server/virtual-linux-server/) which I believe is using "Parallels Virtuozzo Containers" (http://www.parallels.com/products/pvcl/).

----------
nosy: +kleist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:32:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 Jul 2011 11:32:41 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1311679961.97.0.281107408846.issue3581@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What is the output of this command?
   ./python -m test.regrtest -v test_uuid

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:37:12 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 26 Jul 2011 11:37:12 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311680232.83.0.278604662422.issue12380@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Removed file: http://bugs.python.org/file22756/c_format_bytearray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:37:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 26 Jul 2011 11:37:21 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311680241.36.0.69635620271.issue12380@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Removed file: http://bugs.python.org/file22757/c_format_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:38:26 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 26 Jul 2011 11:38:26 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311680306.53.0.621943814684.issue12380@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Updated the bytearray patch to change documentation and add tests.

----------
Added file: http://bugs.python.org/file22764/c_format_bytearray.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:39:35 2011
From: report at bugs.python.org (Karl Johan Kleist)
Date: Tue, 26 Jul 2011 11:39:35 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1311680375.88.0.195336706242.issue3581@psf.upfronthosting.co.za>


Karl Johan Kleist <karl.johan at kleist-it-consulting.de> added the comment:

== CPython 2.7.2 (default, Jul 26 2011, 12:29:47) [GCC 4.2.1 (SUSE Linux)]
==   Linux-2.6.18-028stab091.2-i686-athlon-with-SuSE-10.3-i586 little-endian
==   /home/kjk/local/src/Python-2.7.2/build/test_python_18037
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0)
test_uuid
testIssue8621 (test.test_uuid.TestUUID) ... ok
test_UUID (test.test_uuid.TestUUID) ... ok
test_exceptions (test.test_uuid.TestUUID) ... ok
test_getnode (test.test_uuid.TestUUID) ... ok
test_ifconfig_getnode (test.test_uuid.TestUUID) ... ERROR
test_ipconfig_getnode (test.test_uuid.TestUUID) ... ok
test_netbios_getnode (test.test_uuid.TestUUID) ... ok
test_random_getnode (test.test_uuid.TestUUID) ... ok
test_unixdll_getnode (test.test_uuid.TestUUID) ... ok
test_uuid1 (test.test_uuid.TestUUID) ... ok
test_uuid3 (test.test_uuid.TestUUID) ... ok
test_uuid4 (test.test_uuid.TestUUID) ... ok
test_uuid5 (test.test_uuid.TestUUID) ... ok
test_windll_getnode (test.test_uuid.TestUUID) ... ok

======================================================================
ERROR: test_ifconfig_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kjk/local/src/Python-2.7.2/Lib/test/test_uuid.py", line 306, in test_ifconfig_getnode
    node = uuid._ifconfig_getnode()
  File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 321, in _ifconfig_getnode
    mac = _find_mac('ifconfig', args, ['hwaddr', 'ether'], lambda i: i+1)
  File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 311, in _find_mac
    words[get_index(i)].replace(':', ''), 16)
ValueError: invalid literal for int() with base 16: '00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00'

----------------------------------------------------------------------
Ran 14 tests in 0.315s

FAILED (errors=1)
test test_uuid failed -- Traceback (most recent call last):
  File "/home/kjk/local/src/Python-2.7.2/Lib/test/test_uuid.py", line 306, in test_ifconfig_getnode
    node = uuid._ifconfig_getnode()
  File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 321, in _ifconfig_getnode
    mac = _find_mac('ifconfig', args, ['hwaddr', 'ether'], lambda i: i+1)
  File "/home/kjk/local/src/Python-2.7.2/Lib/uuid.py", line 311, in _find_mac
    words[get_index(i)].replace(':', ''), 16)
ValueError: invalid literal for int() with base 16: '00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00'

1 test failed:
    test_uuid

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:51:31 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 Jul 2011 11:51:31 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1311681091.16.0.293187912126.issue3581@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

hum, maybe an issue with the MAC address of your virtual server? What do you get if you run:
   ifconfig -a | grep -i -e hwaddr -e ether

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Tue Jul 26 13:55:18 2011
From: report at bugs.python.org (Karl Johan Kleist)
Date: Tue, 26 Jul 2011 11:55:18 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1311681318.14.0.683615528967.issue3581@psf.upfronthosting.co.za>


Karl Johan Kleist <karl.johan at kleist-it-consulting.de> added the comment:

> /sbin/ifconfig -a | grep -i -e hwaddr -e ether
venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:15:45 2011
From: report at bugs.python.org (Simon Buchan)
Date: Tue, 26 Jul 2011 12:15:45 +0000
Subject: [issue10469] test_socket fails using Visual Studio 2010
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1311682545.24.0.312963238761.issue10469@psf.upfronthosting.co.za>


Simon Buchan <simon.buchan.nz at gmail.com> added the comment:

Confirming this patch fixes the test_aynsc* tests in my VS10 build. Shouldn't it swap all WSA* defines to protect against this in the future, though? Alternatively, should the check for WSA* codes existing be in Lib\asyncore.py?

----------
nosy: +Simon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:17:01 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 26 Jul 2011 12:17:01 +0000
Subject: [issue3581] failures in test_uuid
In-Reply-To: <1218991997.09.0.347137407735.issue3581@psf.upfronthosting.co.za>
Message-ID: <1311682621.67.0.366183924435.issue3581@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, without a valid MAC address the function cannot work...

On the other hand, I would not worry too much: uuid._ifconfig_getnode() is an internal function; and since all the other tests pass, uuid.getnode() probably has other ways to get a unique identifier for the machine.

And by the way, in python 3.2, the test function is skipped with this message: 
"""WARNING: uuid._ifconfig_getnode is unreliable on many platforms.
   It is disabled until the code and/or test can be fixed properly."""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3581>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:26:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 12:26:38 +0000
Subject: [issue10639] reindent.py converts newlines to platform default
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311683198.83.0.495215276744.issue10639@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22765/900df5732f93.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:33:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 12:33:44 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311683624.03.0.120062194393.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your work.  The generated patch is for some reason unreadable, so I looked at the changeset on Bitbucket.  It looks good, except that a new option would have to be 3.3-only, whereas the bug could be fixed in 2.7 and 3.2 too.  If it?s too bothersome for you to split your current patch, then we can fix in 3.3 only.

----------
title: reindent.py converts newlines to platform default -> reindent.py should not convert newlines
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:38:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 12:38:02 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1311683882.42.0.546856722781.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your tests contain this:

+        sys.path.append(source)

When using regrtest (see http://docs.python.org/devguide/runtests#running), you?ll get a warning that test_packaging altered sys.path.  Your code should make sure sys.path is restored to its previous test:

+        self.addCleanup(sys.path.remove, source)
         sys.path.append(source)

See the unittest.TestCase doc for more about addCleanup and tearDown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:40:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jul 2011 12:40:09 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311684009.13.0.814438266569.issue10639@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file22765/900df5732f93.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:40:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Jul 2011 12:40:34 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311684034.44.0.749907894946.issue10639@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file22766/900df5732f93.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:41:58 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Jul 2011 12:41:58 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311684118.61.0.794401508996.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

No problem. I'll rebase and push the current patch as-is, and then backport to 3.2 and 2.7 without the option (just raising the error when mixed newlines are encountered).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:46:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 12:46:38 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311684398.43.0.413405896821.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> If this changeset is acceptable, I will push the revisions to the
> master repo.

> I'll rebase and push the current patch as-is,

What repo are you talking about, BTW?  The developers list in the devguide does not contain your name, so I assume you?re not talking about hg.python.org/cpython?

> and then backport to 3.2 and 2.7 without the option
IMO it would be easier to make one bugfix changeset in 3.2, merge it in 3.3, and then add the new option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:49:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 12:49:36 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311684576.91.0.357692694885.issue12614@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
hgrepos: +47

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:50:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 12:50:39 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311684639.92.0.204611658021.issue12614@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Roundup can?t connect with SSH, it needs a public HTTP URI.  The one I added requires authentication, can you fix that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Tue Jul 26 14:57:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 12:57:13 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1311685033.0.0.553748923811.issue11797@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

File looks good, although I?m not sure about the ?Copyright 2006 Georg Brandl? line.  I also don?t know if stable branches can get this fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Tue Jul 26 15:24:32 2011
From: report at bugs.python.org (Peter Bumbulis)
Date: Tue, 26 Jul 2011 13:24:32 +0000
Subject: [issue12480] urllib2 doesn't use proxy (fieddler2),
	configed the proxy with ProxyHandler
In-Reply-To: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>
Message-ID: <1311686672.41.0.742782654979.issue12480@psf.upfronthosting.co.za>


Peter Bumbulis <pbumbulis at gmail.com> added the comment:

proxy_bypass_registry in urllib.py does not handle the ProxyOverride registry value properly:  it treats an empty override as *, i.e. bypass the proxy for all hosts.  This behavior does not match other programs (e.g. Chrome) and can be easily obtained by specify * for the override.  One fix would be to ignore empty tests, for example:

    ....
    for test in proxyOverride:
        if test:
            if test == '<local>':
            ...
    return 0
    ....

Perhaps whitespace should be stripped as well.

The problem arises because fiddler2 leaves a trailing ; on the ProxyOverride string.

One possible workaround is to set
    urllib.proxy_bypass = lambda h: 0
to disable bypass checking.  Another alternative would be to specify the proxy settings in the http_proxy environment variable (proxy_bypass_registry is not called in this case).

----------
nosy: +pbumbulis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12480>
_______________________________________

From report at bugs.python.org  Tue Jul 26 15:53:30 2011
From: report at bugs.python.org (Bruce Ferris)
Date: Tue, 26 Jul 2011 13:53:30 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311560689.64.0.570043905551.issue12632@psf.upfronthosting.co.za>
Message-ID: <1311688410.66.0.532718568611.issue12632@psf.upfronthosting.co.za>


Bruce Ferris <bferris57 at bferris.co.uk> added the comment:

Victor, thanks for replying and I've had a quick read of everything that went on for issue #1602.  I think there's some misunderstanding in what I'm saying here.  Maybe this will help clear up what I'm saying...

  D:\>chcp
  Active code page: 850

  D:\>chcp 65001
  Active code page: 65001

  D:\>python27\python
  Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit 
  (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> ^Z

  D:\>python31\python
  Fatal Python error: Py_Initialize: can't initialize sys standard
  streams
  LookupError: unknown encoding: cp65001

  This application has requested the Runtime to terminate it in an
  unusual way.
  Please contact the application's support team for more information.

  D:\>chcp 850
  Active code page: 850

  D:\>python31\python
  Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
  (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> ^Z

  D:\>

You see, I'm NOT trying to output any Unicode or UTF-8 characters.  All I'm trying to do is run different versions of Python on the same machine from the command line.

Some code inside Python now "break" if Python 3.1 is started with Code Page 65001.

I fully understand the change between Python 2.7 and 3.1 were probably due to trying to fix issue #1602 (or some other related issue).

But, as a side-effect to that "fix", if you now start Python 3.1 (and maybe beyond) with code page set to 65001, it refuses to work but it didn't used to refuse to work.

Evidently, Python now tries using the Code Page as an encoding lookup.  But, it didn't used to in 2.7.  So, there's another compatability issue introduced.

Setting my cmd.exe code page to 65001 shouldn't mean a thing to Python if it can't associate it with an encoding.  It could, at least, just switch to 7-Bit ASCII and proceed on.  That would be better than failing!

That's my whole point.  If Python want to do some tweeking with code pages to get it's job done, that's fine by me, as long as it doesn't "break" and restores whatever code page I had set when I started it.

It's not down to a UTF-8 issue, it's about a compatability issue introduced sometime in the last year or so as a side-effect of trying to resolve a UTF-8 issue, probably #1602.

That's all!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Tue Jul 26 16:16:55 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Jul 2011 14:16:55 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311689815.28.0.395777695445.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> I assume you?re not talking about hg.python.org/cpython?

My name appears as jason.coombs. But your note does remind me that I need to review the devguide, since it's been a while since I've pushed something. I may also look into linking/merging my two accounts.

I plan to do as you suggest, splitting the patch into the bugfix and the new capability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 16:24:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 14:24:59 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311690299.8.0.806537441555.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, I hadn?t seen you in http://docs.python.org/devguide/developers and I don?t recall the URI of the generated file with all names.  I?ve asked that your Roundup profile be updated so that you get the Python icon and the possibility to be assigned bugs.

If you already have clones, the workflow should not be hard: go to a 3.2 checkout, fix things, run patchcheck and tests, commit.  Go to 3.3, pull, merge, test, commit, push.  The only tricky things that can make push hooks reject changesets are trailing whitespace, maybe EOLs, and new named branches.  We also prefer to push one changeset with all changes, not a series of changesets with gradual fixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 16:26:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 14:26:49 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1311690409.87.0.830584064644.issue12345@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/issue12345>
_______________________________________

From report at bugs.python.org  Tue Jul 26 16:26:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 14:26:51 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1311690411.63.0.42213479383.issue12345@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22397/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Tue Jul 26 16:32:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jul 2011 14:32:25 +0000
Subject: [issue12632] Windows GPF with Code Page 65001
In-Reply-To: <1311688410.66.0.532718568611.issue12632@psf.upfronthosting.co.za>
Message-ID: <4E2ECFFA.2000202@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>  All I'm trying to do is run different versions of Python on the same machine from the command line.
> Some code inside Python now "break" if Python 3.1 is started with Code Page 65001.

Yes, this issue can be seen as a regression introduced in Python 3.

> I fully understand the change between Python 2.7 and 3.1 were probably due to trying to fix issue #1602 (or some other related issue).

Python 2 and 3 are very different. In Python 2, print "abc" writes a 
byte string to stdout, whereas print("abc") writes a Unicode string to 
stdout. Byte strings and character strings are two different things ;-)

Python 3 now uses Unicode by default and it requires a codec to encode 
strings to stdout. If your program don't output anything to stdout, use 
pythonw.exe instead of python.exe.

The issue #1602 is not specific to Python 3: Python 2 is unable to 
display correctly Unicode strings in the Windows console. It's less 
important in Python 2, because most developers use the default string 
type which is a byte string.

> Setting my cmd.exe code page to 65001 shouldn't mean a thing to Python if it can't associate it with an encoding.  It could, at least, just switch to 7-Bit ASCII and proceed on.  That would be better than failing!

I don't like this idea. In Python, we try to not ignore errors, but try 
instead to fix them or at least fail with an error message (the user is 
responsible to fix it or use a workaround). To fix this issue, we have 
to implement a cp65001 codec for Python or to work directly in Unicode 
using WriteConsole.

If you cannot help to implement one of this option, you can use a 
workaround:

  - don't change the codepage
  - use PYTHONIOENCODING=utf-8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12632>
_______________________________________

From report at bugs.python.org  Tue Jul 26 17:41:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 15:41:24 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311694884.7.0.518968959563.issue10639@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: eric.araujo -> jason.coombs
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 17:54:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 15:54:53 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311695693.03.0.77518201287.issue1626300@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Windows file associations are so disfunctional that you should not
> depend on them being anything in particular.

Ah.  Do you think I should revert the change I did for distutils docs to recommend running ?setup.py spam??  I followed the opinion of the original poster (first message).

> 'python -m module' (which looks for module under /Lib).
Not only under Lib, but along sys.path.

> In XP, and I presume later, the term 'DOS box' is obsolete and I
> would delete it. The 'Command Prompt' app (with caps) is found in
> the Start/Accessories directory. So I would say "open a Command
> Prompt window (in Start/Accessories)"
Thanks, I will change this term.  I won?t put the menu path however, it could change in any version.

> I am not sure of the difference between 'local script' and
> 'global command'.
Chris replied to that: local script is setup.py in a directory you probably just got from unzipping a file downloaded from PyPI, global command is pysetup3, installed alongside idle3, pydoc3 and others.

>> In order to run pysetup commands, you need to add the Python
>> Scripts directory to your PATH *include link to relevant section
>> of docs.python.org/using*.
> I do not understand your proposed note, especially "*include link to
> relevant section of docs.python.org/using*.".
The docs instruct to run pysetup commands, like ?pysetup list? or ?pysetup install Sphinx?.  On UNIX, the script will be available after install just like pydoc or idle.  On Windows, I don?t know.  The goal of my note was to tell people to add the Scripts directory to their PATH, so that they can run ?pysetup list? and co.

The *insert* part meant:  At this place I will put a link to the ?Using Python on...? docs, i.e. http://docs.python.org/using/windows#configuring-python (which explain how to edit PATH).

(Saying pysetup vs. pysetup3 is another unrelated doc bug.)

> Script run without extensions when run with an explicit python
> command.
Like ?python.exe setup? when the file really is setup.py?  I?d never have guessed that.

> I am not sure what 'or does the installer add .py?' could mean.
Do the Windows installers for CPython found on python.org install idle, pydoc and other scripts as ?pydoc? or ?pydoc.py??

> I realize that my answers may appear naive. I hope usefully so.
They?re very useful.

> I have used Windows since Win95 and have learned to focus, as
> described above, on what dependably works with minimal surprise.
This is a very useful standpoint.

> I have never used setup.py so no expert advice on its successor from
> me.
It?s okay, I added you because you can comment on how scripts and programs work, and review my English.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Tue Jul 26 17:56:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 15:56:20 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311695780.78.0.35985266546.issue1626300@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Tue Jul 26 17:59:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jul 2011 15:59:25 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <E1Qlk2W-0004mY-9S@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 070dc6e359fb by Jason R. Coombs in branch '3.2':
Fixes #10639: reindent.py should not convert newlines
http://hg.python.org/cpython/rev/070dc6e359fb

New changeset 826a0208d143 by Jason R. Coombs in branch 'default':
Merge with 3.2 Issue #10639: reindent.py should not convert newlines.
http://hg.python.org/cpython/rev/826a0208d143

New changeset 4feb889d3bed by Jason R. Coombs in branch 'default':
Issue #10639: reindent.py tool now accepts a --newline option to specify the newline to be used in the output of converted files.
http://hg.python.org/cpython/rev/4feb889d3bed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:01:07 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Jul 2011 16:01:07 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311696067.66.0.0639670194603.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've stripped the undesirable revisions and updated the bitbucket repo so it now contains three changesets for Python 3.2 and 3.3 and suggested.

I don't believe running the test suite is relevant, as I grepped the test suite for reindent, and there's no reference to the tool script.

It took several rounds of rebasing and stripping and importing patches to get everything right, but I believe these changes meet the desired goals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:09:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Jul 2011 16:09:45 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311696585.31.0.223156334603.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've stripped the undesirable revisions and updated the bitbucket repo
> so it now contains three changesets for Python 3.2 and 3.3 and
> suggested.

hg diff combined with hg import can help you flatten a series of changeset into one.

> I don't believe running the test suite is relevant
You?re right, I mentioned that step because I was talking about the workflow in general, but here it does not apply, we only have manual testing for most tools.

> I believe these changes meet the desired goals.
Me too!  Are you comfortable with how to backport this to 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:14:18 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Jul 2011 16:14:18 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311696858.0.0.017829280087.issue1626300@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> > Script run without extensions when run with an explicit python
> > command.
> Like ?python.exe setup? when the file really is setup.py?  I?d
> never have guessed that.

No. Python.exe expects the full path. The only way to execute scripts without the extension is if PATHEXT specifies extension and you invoke the script itself, in which case the default handler (for that extension) will be invoked on that file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:25:15 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 26 Jul 2011 16:25:15 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311697515.04.0.651274177774.issue12463@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

In my case, exception occured in separate thread between the begginig of the thread and starting loop.

Main thread has a code that correctly stops that separate thread. It just calls loop_thread.server.server_close() and after that, calls loop_thread.join()

So, if program termination required, but loop was not started, deadlock occur. Moreover, I can not detect if loop was started. And more more over, if I detect that loop was not started, there is chance, that it may be started a bit later, next after my checking. In that case, either loop will not be terminated correctly (if process exits) or join() may block.

So, please DO NOT ADD detection if loop was started. That will generate race-conditions in user code. I think it's never needed. If one wants to detect that, one may use separate variable:
{code}
started = True
xxx.serve_forever() 
{code}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:28:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jul 2011 16:28:37 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1311697515.04.0.651274177774.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311697628.3648.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In my case, exception occured in separate thread between the begginig
> of the thread and starting loop.
> 
> Main thread has a code that correctly stops that separate thread. It
> just calls loop_thread.server.server_close() and after that, calls
> loop_thread.join()
> 
> So, if program termination required, but loop was not started,
> deadlock occur.

Sorry, can you post a snippet reproducing the issue? It will make it
clearer for me to understand it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:39:29 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 26 Jul 2011 16:39:29 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311698369.87.0.796370744712.issue12463@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Why you create variable mirror?
--------------------------
self.__running = False
self.__is_shut_down.set()
--------------------------

You other code is racy. exception may occur at any time.

Why not to test state of __is_shut_down directly ? In any case, server either running either not (i.e. is_shitdown or not is_shutdown). Server should not be tri-state in any case, as I think.

As the latest thing, that serve_forever does - is the calling  self.__is_shut_down.set(). So it is reliable to detect state of the server via state of this lock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:52:21 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 26 Jul 2011 16:52:21 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311699141.09.0.915051235446.issue12463@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

class ThreadedRPC(Thread, SimpleXMLRPCServer):
    def __init__(self):
        Thread.__init__(self)
        SimpleXMLRPCServer.__init__(self)
        # python bug workaround, which eliminate hang on test_exception
        self._BaseServer__is_shut_down.set()
        self.daemon = True

    def run(self):
        raise Exception('race-condition!')
        self.serve_forever()


def main():
    rpc = ThreadedRPC(RPC_LISTEN_ADDR, allow_none=True)
    rpc.start() # from Thread

    # term set by signal handler
    while rpc.isAlive() and not term:
        time.sleep(0.5)

    # note, thread may die in any time! regardles of isAlive()
    # if thread dead before calling serve_forever(), will hang here without a workaround
    rpc.shutdown() # from xmlrpcservr. 

    rpc.join() # from thread (no problem, as thread is not Alive)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 18:59:41 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Jul 2011 16:59:41 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311699581.84.0.669105992392.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

What do you think about this: https://bitbucket.org/jaraco/cpython-issue10639/changeset/ea63310dddce

The patch is a little more intrusive than the Python 3 patch because Python 2.7 doesn't allow specifying the newline to use when writing a file (afaict), but it abstracts that intrusiveness in the NewlineAdapter class.

I've tested the script on a file with mixed newlines, a file with non-native newlines, and a file with content but no newlines, and it performs as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 19:02:31 2011
From: report at bugs.python.org (Jon)
Date: Tue, 26 Jul 2011 17:02:31 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>


New submission from Jon <jon.forums at gmail.com>:

The use of -mno-cygwin at http://bit.ly/qAIsZV causes build failures with versions of MinGW GCC. For example http://bit.ly/llK3f3

I recently ran into it trying to build a Mercurial snapshot using a MinGW GCC v4.6.2 flavor http://pastie.org/2274486

Why is -mno-cygwin still be used, and is there any reason why it can't be removed?

Thanks, Jon

----------
assignee: tarek
components: Distutils
messages: 141172
nosy: eric.araujo, jonforums, tarek
priority: normal
severity: normal
status: open
title: Remove -mno-cygwin from distutils
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Jul 26 20:06:41 2011
From: report at bugs.python.org (Ruben Van Boxem)
Date: Tue, 26 Jul 2011 18:06:41 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311703601.7.0.654357087577.issue12641@psf.upfronthosting.co.za>


Ruben Van Boxem <vanboxem.ruben at gmail.com> added the comment:

I can confirm the option has been removed. For those that don't want to believe a random person's comment on a bugtracker, here's the commit:

http://repo.or.cz/w/official-gcc.git/commit/2637551aa9314c46cf4205d435ab5e8944e9ac8a

The changelog is a bit cryptic, but note the last two items "removing documentation from removed option".

----------
nosy: +rubenvb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Jul 26 20:07:46 2011
From: report at bugs.python.org (Kevin Stock)
Date: Tue, 26 Jul 2011 18:07:46 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1311703666.78.0.227640576918.issue12629@psf.upfronthosting.co.za>


Kevin Stock <teoryn at gmail.com> added the comment:

A workaround is to call close() after feed(), which I supposed I should have done anyways. However, this does not resolve the issue that the two cases behave so differently. 

The code that causes the difference is lines 351-355 of parser.py, which also has a misleading comment stating it detects the / in a /> ending (which is actually done at 334).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12629>
_______________________________________

From report at bugs.python.org  Tue Jul 26 20:20:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Jul 2011 18:20:02 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311704402.58.0.905799561206.issue1626300@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe I meant that 'python setup' works when the script is named 'setup'. Which is to say, python does not require scripts to have an extension, as someone had thought in writing a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Tue Jul 26 20:27:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Jul 2011 18:27:57 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1311704877.54.0.175219747295.issue1626300@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I do not know why the msi installer *silently* fails to properly register extensions even when I leave that checked, or how common that it. I have never looked into the issue more because for development, I prefer to run from an IDLE window and be dumped into the shell after and have a chance to examine data and re-call functions. I will soon do an install on a new machine, so I will see what a true 'default' install looks like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Tue Jul 26 20:31:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 26 Jul 2011 18:31:51 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1311705111.02.0.489252114401.issue3526@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Fortunately, it is easy to solve by defining the following in
> dlmalloc:
> #define HAVE_MORECORE 0

I was expecting this answer ;-)
Here's a quick demo, on a Linux box:

cf at neobox:~/cpython$ ./python Tools/pybench/pybench.py -n 1
-------------------------------------------------------------------------------
Totals:                          19787ms  19787ms

cf at neobox:~/cpython$ MALLOC_MMAP_THRESHOLD_=0 ./python Tools/pybench/pybench.py -n 1
[...]
-------------------------------------------------------------------------------
Totals:                          33375ms  33375ms

That's a mere 70% slowdown, and without pymalloc, it would be much worse. malloc with mmap() is way slower than with sbrk() (see http://sources.redhat.com/ml/libc-alpha/2006-03/msg00033.html for more details). Since your benchmarks don't show this type of regression it probably means that AIX's malloc implementation is really broken (there's also the fact that part of the allocations are still routed to the libc's malloc, or maybe your workload is too specific to demonstrate this behavior).

> sbrk is generally considered quite archaic.

I wouldn't say that; see the above link on malloc's dynamic mmap() threshold.

> I also don't expect this patch to be integrated spontaneously without
> someone interested in AIX pushing for it.

Indeed.
As far as I'm concerned, there are two "showstoppers":
- shipping an implementation of dlmalloc with Python
- mixing dlmalloc with the host's malloc implementation

But I think the main problem with this patch is that AIX represents such a tiny fraction of the user base. This might change in the future, especially if IBM is successfull in its effort of pushing AIX (I hope they'll finally fix AIX's malloc by then...).

> I have been quite busy recently with the birth of my second daughter,
> a new job, a new home town and soon a new home.

Congratulations, and good luck!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Tue Jul 26 22:33:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jul 2011 20:33:52 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1311699141.09.0.915051235446.issue12463@psf.upfronthosting.co.za>
Message-ID: <1311712343.3596.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

[...]
>     # note, thread may die in any time! regardles of isAlive()
>     # if thread dead before calling serve_forever(), will hang here without a workaround
>     rpc.shutdown() # from xmlrpcservr. 

Why do you say it "hangs"? It doesn't hang, it just waits for you to
call serve_forever(): it's not a bug, it's actually a feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 22:34:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jul 2011 20:34:12 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311712452.43.0.152242320816.issue10639@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/issue10639>
_______________________________________

From report at bugs.python.org  Tue Jul 26 22:56:48 2011
From: report at bugs.python.org (phep)
Date: Tue, 26 Jul 2011 20:56:48 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311713808.12.0.227146380273.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

Hi,

This was test code :-/. It was not under revision control and 
unfortunately, as I feared then, it turned out I had to stop
working shortly after my last message on the low-priority
project that made me report this issue .

Yet, I have a tarball of a presumably-not-so-different version
of the code and I experimented with it this afternoon. Actually,
I could not reproduce the problem I reported in msg117933. So, 
basically, the idea of replacing tempfile.TemporaryFile() by
tempfile.NamedTemporaryFile() seems to really be valid, whatever
the position of the form field.

Yet I found another problem, quite reproducible that one, that
seems to have some fame on Google. Due to the way cgi.__write()
is written, contents of uploaded files with small sizes will be
stored as StringIO. Consequently, sort-of calling
fieldstorage['filenamefield'].file.name will fail. De facto,
this may actually be the error I alluded to in msg117933 - I 
honestly cannot remember what I observed then: ? c'est
l'?ge...?.

So the patch should then be one line longer: we would need
to change __write() to add a check on the value of 'filename' :
-           if self.__file.tell() + len(line) > 1000:
+           if self.filename or self.__file.tell() + len(line) > 1000:

This way, long textareas (for example), keep being stored on
disk if this has any importance.

There is yet one question I cannot answer: where does the 1ko 
barrier come from? Was it only chosen out of performance
considerations, or was there another reason? As I am quite new 
to Python I fear I may miss something obvious.

HTH

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Tue Jul 26 22:57:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 26 Jul 2011 20:57:48 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <20110726103155.GA2095@ihaa>
Message-ID: <CAH_1eM1bqudhpc=8JEBCpkqFcZHymxMyJSYMP8Cy_g6UArE2cQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> If someone suggests how to test for the Windows version, I'll update
> the patch, also to remove the issue reference from the code.

Well, I don't know Windows, but there's platform.win32_ver()
(http://docs.python.org/library/platform.html#platform.win32_ver) that
could probably be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Tue Jul 26 22:59:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Jul 2011 20:59:51 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1311713991.61.0.588164314807.issue8746@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:00:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jul 2011 21:00:21 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <E1Qlojd-0007tM-Bs@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ca236138f0ce by Ned Deily in branch '2.7':
Issue #8746: Use tempfile module to get tempdir and randomize the
http://hg.python.org/cpython/rev/ca236138f0ce

New changeset 4e4554aa1453 by Ned Deily in branch '3.2':
Issue #8746: Use tempfile module to get tempdir and randomize the
http://hg.python.org/cpython/rev/4e4554aa1453

New changeset 080035e58bab by Ned Deily in branch 'default':
Issue #8746: Use tempfile module to get tempdir and randomize the
http://hg.python.org/cpython/rev/080035e58bab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:03:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jul 2011 21:03:56 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <CAH_1eM1bqudhpc=8JEBCpkqFcZHymxMyJSYMP8Cy_g6UArE2cQ@mail.gmail.com>
Message-ID: <1311714145.8406.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can simply use support.skip_unless_symlink().

> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
> 
> > If someone suggests how to test for the Windows version, I'll update
> > the patch, also to remove the issue reference from the code.
> 
> Well, I don't know Windows, but there's platform.win32_ver()
> (http://docs.python.org/library/platform.html#platform.win32_ver) that
> could probably be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:20:19 2011
From: report at bugs.python.org (Jann Eike Kruse)
Date: Tue, 26 Jul 2011 21:20:19 +0000
Subject: [issue12642] 2.6.6 documentation of the  open()  built-in function
In-Reply-To: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>
Message-ID: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>


New submission from Jann Eike Kruse <python at jannkruse.de>:

The documentation page 

http://docs.python.org/release/2.6.6/library/functions.html?highlight=open#open

describes the  open()  built-in function as

  open(filename[, mode[, bufsize]])

but the Python interpreter complains:

  Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
  [GCC 4.4.5] on linux2 
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 
  >>> 
  >>> file_descriptor = open(filename='/spam')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: Required argument 'name' (pos 1) not found
  >>> 
  >>> 
  >>> file_descriptor = open(name='/spam', bufsize=-1)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: 'bufsize' is an invalid keyword argument for this function
  >>> 
  >>> 
  >>> file_descriptor = open(name='/spam', buffering=-1)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  IOError: [Errno 2] No such file or directory: '/spam'
  >>> _
  

So the documentation page should read

  open(name[, mode[, buffering]])
       ----          ---------

instead, note 'name' not 'filename' and 'buffering' not 'bufsize'.

Maybe it's relevant, because Debian/stable still ships with
Python 2.6.6 and I guess the Python 2.7.x documentation has 
the same bug.

The """docstring""" does already reflect that correctly.


PS:
This is my first bug report. I hope I did this right. 
Mercy, please! ;)

----------
assignee: docs at python
components: Documentation
messages: 141183
nosy: docs at python, jannkruse
priority: normal
severity: normal
status: open
title: 2.6.6 documentation of the  open()  built-in function
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12642>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:28:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 26 Jul 2011 21:28:42 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1311712343.3596.1.camel@localhost.localdomain>
Message-ID: <CAH_1eM3ji+ecQvF+3Y0y+6pg-rp6PNANBEDk-OEgr_AiY5VjDg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

When you join a thread which hasn't been started, you get an
exception, not a deadlock.
When you join a newly-created queue, it doesn't wait until an item is
submitted to the queue.
But honestly I don't really care, since it's such a minor nuisance and
open to interpretation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:30:59 2011
From: report at bugs.python.org (Dustin Haffner)
Date: Tue, 26 Jul 2011 21:30:59 +0000
Subject: [issue12063] tokenize module appears to treat unterminated single and
	double-quoted strings inconsistently
In-Reply-To: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>
Message-ID: <1311715859.55.0.444630231361.issue12063@psf.upfronthosting.co.za>


Changes by Dustin Haffner <nitsud at gmail.com>:


----------
nosy: +dhaffner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12063>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:34:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jul 2011 21:34:28 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <CAH_1eM3ji+ecQvF+3Y0y+6pg-rp6PNANBEDk-OEgr_AiY5VjDg@mail.gmail.com>
Message-ID: <1311715978.8406.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> When you join a thread which hasn't been started, you get an
> exception, not a deadlock.

But we don't have a deadlock here: another thread could perfectly well
call serve_forever() in the meantime and shutdown() should then return
after having stopped the event loop.

My point is that changing semantics may break existing software, without
there being a clear benefit in doing so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12463>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:42:52 2011
From: report at bugs.python.org (phep)
Date: Tue, 26 Jul 2011 21:42:52 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311716572.57.0.453797640098.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

Oh, my...

As we are working with python2.6 on our servers, I overlooked the fact that tempfile.NamedTemporaryFile was already used in python 3 (fixed in r57595, with not many explanations though).

Yet, the problem with short length files (cf. msg141179) is still valid and the documentation has not yet been updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:53:58 2011
From: report at bugs.python.org (phep)
Date: Tue, 26 Jul 2011 21:53:58 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311717238.18.0.465703731485.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

I got my head in a brown paper bag.... 

This is obviously not fixed... except in a locally edited checkout :-(

Please be kind to the tired me, forget my last message and don't talk about this to my boss, will you ?

It's closing time, really.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Tue Jul 26 23:58:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jul 2011 21:58:48 +0000
Subject: [issue12642] Python2 documentation of the  open()  built-in function
In-Reply-To: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>
Message-ID: <1311717528.96.0.571681932225.issue12642@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The docs are correct in Python3.

The docs for Python2 are not *wrong*, since they indicate only positional parameters and if you use positional parameters it works as documented. (I'm surprised that using keyword arguments works, but I haven't looked at the code.)  Fixing the names in the 2.7 docs would still be helpful (2.6 docs don't get updated any more).

----------
nosy: +r.david.murray
priority: normal -> low
stage:  -> needs patch
title: 2.6.6 documentation of the  open()  built-in function -> Python2 documentation of the  open()  built-in function
type:  -> behavior
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12642>
_______________________________________

From report at bugs.python.org  Wed Jul 27 00:05:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jul 2011 22:05:42 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311717942.07.0.567239428853.issue12607@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

i12607_v2.patch: the test fails if Python is compiled with pydebug. Add "err = support.strip_python_stderr(err)" before self.assertEqual(err, b"err") in test_subprocess.py to fix the failure.

----------
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Wed Jul 27 00:50:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jul 2011 22:50:19 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1311720619.06.0.247695360143.issue1813@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The Fedora bot fails because here ...

  locale.setlocale(locale.LC_CTYPE, loc)

loc = ('tr_TR', 'ISO8859-9'), and apparently setlocale can only
handle "tr_TR", but not "tr_TR.ISO8859-9":



144         if (locale) {
145             /* set locale */
146             result = setlocale(category, locale);
147             if (!result) {
148                 /* operation failed, no setting was changed */
149                 PyErr_SetString(Error, "unsupported locale setting");
150                 return NULL;
(gdb) p result = setlocale(category, "tr_TR.ISO8859-9")
$8 = 0x0
(gdb) p result = setlocale(category, "tr_TR")
$9 = 0x96d770 "tr_TR"
(gdb) p locale
$10 = 0x7ffff0f6a5b0 "tr_TR.ISO8859-9"
(gdb)

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:01:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jul 2011 23:01:52 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1311720619.06.0.247695360143.issue1813@psf.upfronthosting.co.za>
Message-ID: <20110726225930.GA23585@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Stefan Krah <report at bugs.python.org> wrote:
> (gdb) p result = setlocale(category, "tr_TR.ISO8859-9")
> $8 = 0x0
> (gdb) p result = setlocale(category, "tr_TR")
> $9 = 0x96d770 "tr_TR"
> (gdb) p locale
> $10 = 0x7ffff0f6a5b0 "tr_TR.ISO8859-9"
> (gdb)

Perhaps this is a bug in Fedora's setlocale that can't handle the turkish 'I'
in 'ISO' when CTYPE is turkish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:01:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jul 2011 23:01:54 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1311721314.96.0.879822420873.issue12181@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

select.kevent(bignum, 1, 2, 3, sys.maxsize, bignum) raises a OverflowError('signed integer is greater than maximum') on a 64 bits system. select.kevent() constructor parses the 4th argument using "i" (an int): sys.maxsize doesn't fit in a C int on a 64 bits system.

kevent() constructor parses the 4th argument using "i", but it pass a pointer to a void* value (e->udata). It would be better to use a temporary C int variable, and then write the int into udata using the right cast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:02:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jul 2011 23:02:52 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <20110726225930.GA23585@sleipnir.bytereef.org>
Message-ID: <1311721284.8406.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Stefan Krah <report at bugs.python.org> wrote:
> > (gdb) p result = setlocale(category, "tr_TR.ISO8859-9")
> > $8 = 0x0
> > (gdb) p result = setlocale(category, "tr_TR")
> > $9 = 0x96d770 "tr_TR"
> > (gdb) p locale
> > $10 = 0x7ffff0f6a5b0 "tr_TR.ISO8859-9"
> > (gdb)
> 
> Perhaps this is a bug in Fedora's setlocale that can't handle the turkish 'I'
> in 'ISO' when CTYPE is turkish.

Perhaps indeed. Maybe you should try to report it.
It does look like an OS bug in any case.
(fortunately that buildbot is in the "unstable" bunch :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:05:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jul 2011 23:05:44 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1311721544.94.0.992973112075.issue12181@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

OpenBSD has a patch for this issue:
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.7/patches/patch-Modules_selectmodule_c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:15:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Jul 2011 23:15:30 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1311722130.32.0.0291837659446.issue12181@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

patch-Modules_selectmodule_c is not enough to fix kqueue_event_init(): it doesn't catch overflow error on the ident attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:17:11 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Jul 2011 23:17:11 +0000
Subject: [issue12480] urllib2 doesn't use proxy (fieddler2),
	configed the proxy with ProxyHandler
In-Reply-To: <1309706172.79.0.961224445373.issue12480@psf.upfronthosting.co.za>
Message-ID: <1311722231.81.0.731129093715.issue12480@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12480>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:35:00 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jul 2011 23:35:00 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1311723300.17.0.725248729896.issue1813@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, it's a bug. This works:

#include <stdio.h>
#include <locale.h>
int
main(void)
{
    char *s;
    printf("%s\n", setlocale(LC_CTYPE, "tr_TR.ISO8859-9"));
    printf("%s\n", setlocale(LC_CTYPE, NULL));
    s = setlocale(LC_CTYPE, "tr_TR.ISO8859-9");
    printf("%s\n", s ? s : "null");
    return 0;
}

But when I change the first setlocale call to "tr_TR", the result of
the last call is NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:49:15 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 26 Jul 2011 23:49:15 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311724155.03.0.198528002607.issue12614@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
hgrepos: +48

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:50:33 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 26 Jul 2011 23:50:33 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311724233.69.0.452432455713.issue12614@psf.upfronthosting.co.za>


Changes by Miki Tebeka <miki.tebeka at gmail.com>:


----------
hgrepos: +49

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:52:37 2011
From: report at bugs.python.org (Dan Colish)
Date: Tue, 26 Jul 2011 23:52:37 +0000
Subject: [issue1602133] non-framework python fails to define os.environ
	properly
Message-ID: <1311724357.54.0.882003409593.issue1602133@psf.upfronthosting.co.za>


Dan Colish <dcolish at gmail.com> added the comment:

I can also confirm this patch is required to build py2cairo on OSX with Python2.7.2 when --enable-framework is not used.

----------
nosy: +dcolish

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602133>
_______________________________________

From report at bugs.python.org  Wed Jul 27 01:52:55 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 26 Jul 2011 23:52:55 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311724375.35.0.763945208205.issue12614@psf.upfronthosting.co.za>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

My bad about the hg location, it was a private repo (for some reason this is the bitbucket default).

I tried to remove the other repos, but for some reason this doesn't work. The right one is https://bitbucket.org/tebeka/cpython#request-method

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Wed Jul 27 02:25:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 00:25:57 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <E1Qlrwi-0007su-FQ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9eac48fbe21d by Senthil Kumaran in branch '3.2':
Fix closes Issue12576 - fix urlopen behavior on sites which do not send (or obsfuscates) Connection: Close header.
http://hg.python.org/cpython/rev/9eac48fbe21d

New changeset a45c8ce67c7d by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes Issue12576 - fix urlopen behavior on sites which do not send (or obsfuscates) Connection: Close header.
http://hg.python.org/cpython/rev/a45c8ce67c7d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Wed Jul 27 03:19:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 01:19:54 +0000
Subject: [issue12590] First line and cursor not visible when opening files
In-Reply-To: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>
Message-ID: <E1Qlsmu-0003c6-N1@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 73ae3729b8fe by Ned Deily in branch '2.7':
Issue #12590: IDLE editor window now always displays the first line
http://hg.python.org/cpython/rev/73ae3729b8fe

New changeset 1c8aca41845c by Ned Deily in branch '3.2':
Issue #12590: IDLE editor window now always displays the first line
http://hg.python.org/cpython/rev/1c8aca41845c

New changeset b782d7c59f69 by Ned Deily in branch 'default':
Issue #12590: IDLE editor window now always displays the first line
http://hg.python.org/cpython/rev/b782d7c59f69

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12590>
_______________________________________

From report at bugs.python.org  Wed Jul 27 03:26:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 27 Jul 2011 01:26:46 +0000
Subject: [issue12590] First line and cursor not visible when opening files
In-Reply-To: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>
Message-ID: <1311730006.6.0.268397634636.issue12590@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report and the cite.

The problem appears to be a difference in behavior between Tk 8.5 and earlier versions of Tk and not a platform difference.  The fix is to use that 'yview' method of Text instead of 'see'.  That gives the expected behavior with both Tk 8.5 and 8.4.   Fix is applied to 2.7 (for 2.7.3), 3. 2 (for 3.2.2), and default (for 3.3).  Only security issues are accepted for Python 2.6 but the patch should apply and work there as well.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12590>
_______________________________________

From report at bugs.python.org  Wed Jul 27 03:32:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 01:32:21 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <E1Qlsyx-0004VT-Oh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d58b43fb9208 by Senthil Kumaran in branch '3.2':
Correcting issue 12576 fix, which resulted in buildbot failures.
http://hg.python.org/cpython/rev/d58b43fb9208

New changeset dcfce522723d by Senthil Kumaran in branch 'default':
merge from 3.2 - Correcting issue 12576 fix, which resulted in buildbot failures.
http://hg.python.org/cpython/rev/dcfce522723d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Wed Jul 27 05:06:08 2011
From: report at bugs.python.org (Simon Forman)
Date: Wed, 27 Jul 2011 03:06:08 +0000
Subject: [issue12590] First line and cursor not visible when opening files
In-Reply-To: <1311131541.7.0.783238761563.issue12590@psf.upfronthosting.co.za>
Message-ID: <1311735968.25.0.0380934672513.issue12590@psf.upfronthosting.co.za>


Simon Forman <forman.simon at gmail.com> added the comment:

You're very welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12590>
_______________________________________

From report at bugs.python.org  Wed Jul 27 05:24:51 2011
From: report at bugs.python.org (Matt Basta)
Date: Wed, 27 Jul 2011 03:24:51 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311737091.98.0.678032127976.issue670664@psf.upfronthosting.co.za>


Matt Basta <bastawhiz at gmail.com> added the comment:

The number of problems produced by this bug can be greatly reduced by adding a relatively small check to the parser. Currently, <script> and <style> tags call set_cdata_mode(), which sets self.interesting to HTMLParser.interesting_cdata. This is bad because it searches for ANY closing tag, rather than a closing tag which matches the opening tag.

Alexander's fix solved about half the problem, but it didn't handle ending tags as text. I've fixed this and added some tests.

This is my first patch, so if there's a better way that I could be submitting this, input would be appreciated.

----------
nosy: +Matt.Basta
Added file: http://bugs.python.org/file22767/hp_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 05:31:27 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 03:31:27 +0000
Subject: [issue12642] Python2 documentation of the  open()  built-in function
In-Reply-To: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>
Message-ID: <1311737487.46.0.751929311209.issue12642@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/issue12642>
_______________________________________

From report at bugs.python.org  Wed Jul 27 06:01:53 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 27 Jul 2011 04:01:53 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1311739313.45.0.38831618892.issue10854@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

How about something like this?

ImportError moves from being a "simple" exception to a "complex" one, then adds a "name" and "path" attribute. In dynload_win.c where we try (and fail) to load C extensions, the name and path are set on the ImportError. The test simply creates a file following the C extension name format and checks that the attributes end up being correct upon ImportError.

Jazzing up the ImportErrors elsewhere in the code might be useful after this, but I'll handle that in another issue if this gains traction.

----------
keywords: +patch
Added file: http://bugs.python.org/file22768/issue10854.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Wed Jul 27 07:47:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 05:47:17 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <E1Qlwxf-0006TT-Og@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1140b32747c9 by Ross Lagerwall in branch '3.2':
Issue #12607: In subprocess, fix issue where if stdin, stdout or stderr is
http://hg.python.org/cpython/rev/1140b32747c9

New changeset 943d323cb4b8 by Ross Lagerwall in branch 'default':
Issue #12607: Merge with 3.2.
http://hg.python.org/cpython/rev/943d323cb4b8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Wed Jul 27 07:49:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 05:49:04 +0000
Subject: [issue12642] Python2 documentation of the  open()  built-in function
In-Reply-To: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>
Message-ID: <E1QlwzP-0006XK-40@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5da7924c4775 by Ezio Melotti in branch '2.7':
#12642: fix args names in open() doc.
http://hg.python.org/cpython/rev/5da7924c4775

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12642>
_______________________________________

From report at bugs.python.org  Wed Jul 27 07:50:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jul 2011 05:50:31 +0000
Subject: [issue12642] Python2 documentation of the  open()  built-in function
In-Reply-To: <1311715219.77.0.164344328426.issue12642@psf.upfronthosting.co.za>
Message-ID: <1311745831.43.0.857335686481.issue12642@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12642>
_______________________________________

From report at bugs.python.org  Wed Jul 27 07:53:19 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Jul 2011 05:53:19 +0000
Subject: [issue10854] Output .pyd name in error message of ImportError when
	DLL load fails
In-Reply-To: <1294415325.09.0.315523226252.issue10854@psf.upfronthosting.co.za>
Message-ID: <1311745999.15.0.798386786516.issue10854@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

See also #1559549, which similarly adds attribute support to ImportError and covers some of the issues with using positional arguments to do so.

Extending that approach to a path keyword argument as well should work nicely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10854>
_______________________________________

From report at bugs.python.org  Wed Jul 27 08:52:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jul 2011 06:52:15 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311749535.43.0.630839370937.issue670664@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I left a review about your patch on rietveld, including a description of what I think it's going on there (the patch lacks some context and it's not easy to figure out how everything works there).
I also did some tests with and without the patch:

>>> from HTMLParser import HTMLParser as HP
>>> class MyHP(HP):
...   def handle_data(self, data): print 'data: %r' % data
... 
>>> myhp = MyHP()

# without the patch:
>>> myhp.feed('<script>foobar</script>')
data: 'foobar'  # this looks ok
>>> myhp.feed('<script><p>foo</p></script>')
data: '<p>foo'  # where's the </p>?
>>> myhp.feed('<script><p>foo</p><span>bar</span></script>')
data: '<p>foo' # some tags missing, 2 chunks received
data: 'bar'
>>> myhp.feed("<script><p>foo</p> '</scr'+'ipt>' <span>bar</span></script>")
data: '<p>foo'
data: " '"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/HTMLParser.py", line 108, in feed
    self.goahead(0)
  File "/usr/lib/python2.7/HTMLParser.py", line 150, in goahead
    k = self.parse_endtag(i)
  File "/usr/lib/python2.7/HTMLParser.py", line 317, in parse_endtag
    self.error("bad end tag: %r" % (rawdata[i:j],))
  File "/usr/lib/python2.7/HTMLParser.py", line 115, in error
    raise HTMLParseError(message, self.getpos())
HTMLParser.HTMLParseError: bad end tag: "</scr'+'ipt>", at line 1, column 247


# with the patch:
>>> myhp.feed('<script>foobar</script>')
data: 'foobar'  # ok
>>> myhp.feed('<script><p>foo</p></script>')
data: '<p>foo' # all the content is there, but why 2 chunks?
data: '</p>'
>>> myhp.feed('<script><p>foo</p><span>bar</span></script>')
data: '<p>foo' # same as previous
data: '</p>'
data: '<span>bar'
data: '</span>'
>>> myhp.feed("<script><p>foo</p> '</scr'+'ipt>' <span>bar</span></script>")  
data: '<p>foo' # same
data: '</p>'
data: " '"
data: "</scr'+'ipt>"
data: "' <span>bar"
data: '</span>'

So my question is: is it normal that the data is passed to handle_data in chunks?
AFAIU HTML parser should see CDATA as a single chunk of bytes they don't care about, so the fact that further parsing happens on the content of script/style seems wrong to me.
If I'm reading the code correctly that's because the "interesting" regex is set to look for a closing tag ('</') -- maybe assuming that the CDATA section doesn't contain any other tag (usually true in case of <style>, often false for <script>).
Changing the regex to explicitly look for the closing tag might be better (but still fail for e.g. <script> document.write('<script>alert("foo")</script>')</script> -- but some browsers will fail with this too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 09:24:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 07:24:34 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1311722130.32.0.0291837659446.issue12181@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1s-S_mb7P7JP7oiW2gE_BkAgcdfxeevyj5cZ5NkOC2+g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> patch-Modules_selectmodule_c is not enough to fix kqueue_event_init(): it doesn't catch overflow error on the ident attribute.

This patch is not correct.

Furthermore, it's another occurrence of something I don't understand
with distributions: why apply a patch to their tree and not submit it
upstream?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jul 27 10:18:08 2011
From: report at bugs.python.org (Federico Schwindt)
Date: Wed, 27 Jul 2011 08:18:08 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1311754688.78.0.42509958379.issue12181@psf.upfronthosting.co.za>


Federico Schwindt <federico.schwindt at gmail.com> added the comment:

I wrote the patch. While the patch fixes most of the issues I'm not entirely happy with it and that's the reason I have not submitted it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jul 27 10:54:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 08:54:32 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1311754688.78.0.42509958379.issue12181@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0uPtZg+D2BsfK=FipMBFqv9w+YPLdYKP+pcosK_AQjag@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I wrote the patch. While the patch fixes most of the issues I'm not entirely happy with it and that's the reason I have not submitted it.

Could you submit it here so that we can help you get it in shape for inclusion?
That way we'll all benefit from the work you've already done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed Jul 27 12:02:44 2011
From: report at bugs.python.org (Ask Solem)
Date: Wed, 27 Jul 2011 10:02:44 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1311760964.66.0.658932598581.issue6288@psf.upfronthosting.co.za>


Ask Solem <ask at celeryproject.org> added the comment:

How would you replace the following functionality
with the multiple with statement syntax:


    x = (A(), B(), C())
    with nested(*x) as context:
        ....


It seems to me that nested() is still useful for this particular
use case.

----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Wed Jul 27 12:16:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 10:16:08 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1311761768.18.0.485230897229.issue12464@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached an updated patch:

- the test now uses support.skip_unless_symlink decorator

- added an explicit assertion ensuring that the contents of the linked directory aren't deleted

- removed issue reference from the code

----------
Added file: http://bugs.python.org/file22769/issue12464_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Wed Jul 27 12:18:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 10:18:09 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1311761889.82.0.983116406837.issue12170@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Ok, so the current raising semantics should be good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed Jul 27 12:35:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 10:35:59 +0000
Subject: [issue12381] refactor slice checks made by methods that take "slice
	like" arguments
In-Reply-To: <1308628637.29.0.156287318778.issue12381@psf.upfronthosting.co.za>
Message-ID: <1311762959.45.0.620937992962.issue12381@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

R. David Murray wrote:
> Note that both of these have been fixed in default, so I'm
> repurposing this issue for the refactoring I suggested.
> However, since I can't find an existing issue for the bytearray
> fix, maybe somebody already did it and I didn't notice.

It seems to me that such refactorization has been already done when fixing issue 11828. The stringlib_parse_args_finds() function is used to to parse the slice-like arguments of str, bytes and bytearray functions.

As the errors reported in the issue have already been fixed in all branches, I'm closing this as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12381>
_______________________________________

From report at bugs.python.org  Wed Jul 27 12:41:30 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 10:41:30 +0000
Subject: [issue12294] multiprocessing.Pool: Need a way to find out if work are
	finished.
In-Reply-To: <1307627992.49.0.467043384727.issue12294@psf.upfronthosting.co.za>
Message-ID: <1311763290.39.0.020707619684.issue12294@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +easy
nosy: +jnoller
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12294>
_______________________________________

From report at bugs.python.org  Wed Jul 27 12:45:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 10:45:14 +0000
Subject: [issue12631] Mutable Sequence Type in .remove() is consistent only
	with lists, but not with bytearrays
In-Reply-To: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>
Message-ID: <1311763514.92.0.140148106645.issue12631@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Duplicate of issue 12170.

----------
nosy: +petri.lehtinen
superseder:  -> index() and count() methods of bytes and bytearray should accept byte ints

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12631>
_______________________________________

From report at bugs.python.org  Wed Jul 27 13:17:56 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 11:17:56 +0000
Subject: [issue12595] python.h redundant redeclarations
In-Reply-To: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>
Message-ID: <1311765476.38.0.420474911615.issue12595@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Already fixed in 3.3 as a part of issue 8914. This does not cause a compilation failure with the default build flags, so there's no need to backport to older versions.

Closing as duplicate of issue 8914.

----------
nosy: +petri.lehtinen
resolution:  -> duplicate
status: open -> closed
superseder:  -> Run clang's static analyzer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12595>
_______________________________________

From report at bugs.python.org  Wed Jul 27 13:19:25 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 11:19:25 +0000
Subject: [issue12595] python.h redundant redeclarations
In-Reply-To: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>
Message-ID: <1311765565.17.0.849144787643.issue12595@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

After hitting the submit button, I realized that Python.h is of course included when embedding Python, so the fix could be backported to 3.2.

----------
keywords: +easy
resolution: duplicate -> 
stage:  -> needs patch
status: closed -> open
superseder: Run clang's static analyzer -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12595>
_______________________________________

From report at bugs.python.org  Wed Jul 27 13:52:47 2011
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=)
Date: Wed, 27 Jul 2011 11:52:47 +0000
Subject: [issue9090] Error code 10035 calling socket.recv() on a socket with a
	timeout (WSAEWOULDBLOCK - A non-blocking socket operation could
	not be completed immediately)
In-Reply-To: <1277602727.58.0.118328870924.issue9090@psf.upfronthosting.co.za>
Message-ID: <1311767567.3.0.133084363242.issue9090@psf.upfronthosting.co.za>


Bj?rn Lindqvist <bjourne at gmail.com> added the comment:

I don't have the expertise to backport it myself, but the problem certainly is still present in python 2.7.1 on Windows 7. It is especially pronounced when using threading to read from multiple url files.

----------
nosy: +bjourne

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9090>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:04:51 2011
From: report at bugs.python.org (junior1971)
Date: Wed, 27 Jul 2011 12:04:51 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1311768291.5.0.447121841797.issue12029@psf.upfronthosting.co.za>


Changes by junior1971 <junior1971 at meta.ua>:


Added file: http://bugs.python.org/file22770/cheapcodfedextramadolvery.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:10:07 2011
From: report at bugs.python.org (aliles)
Date: Wed, 27 Jul 2011 12:10:07 +0000
Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>


New submission from aliles <aaron.iles at gmail.com>:

code.InteractiveConsole doesn't match the CPython interactive interpreter with respect to allowing sys.excepthook to handle exceptions. Unlike the interactive interpreter, replacing sys.excepthook with an alternate function will not change exception handling behaviour from inside a code.InteractiveConole

This affects downstream interpreters such as PyPy.
https://bugs.pypy.org/issue811

----------
components: Library (Lib)
files: console.py
messages: 141222
nosy: aliles
priority: normal
severity: normal
status: open
title: code.InteractiveConsole ignores sys.excepthook
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22771/console.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12643>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:25:59 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Jul 2011 12:25:59 +0000
Subject: [issue6288] Update contextlib.nested docs in light of deprecation
In-Reply-To: <1245102189.2.0.00392930921472.issue6288@psf.upfronthosting.co.za>
Message-ID: <1311769559.95.0.00042749926323.issue6288@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed it is, although we think actually doing that is a bad idea (as discussed earlier on this tracker item).

See the 3.1 docs for the recommended workaround for the removal (basically grab a copy of the 3.1 code and drop it into your own utility module)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6288>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:29:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jul 2011 12:29:46 +0000
Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311769786.32.0.258735310245.issue12643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What do you suggest?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12643>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:43:29 2011
From: report at bugs.python.org (aliles)
Date: Wed, 27 Jul 2011 12:43:29 +0000
Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311770609.64.0.662304855215.issue12643@psf.upfronthosting.co.za>


aliles <aaron.iles at gmail.com> added the comment:

OK. Not something I was expecting to be asked. But cool :D

If it's not possible for InteractiveConsole to allow exceptions to propagate through sys.excepthook. (I assume they are being caught in a try: catch: block) check sys.excepthook for a custom exception handler and call present.

As InteractiveConsole is supposed to "Closely emulate the behaviour of the interactive Python interpreter", any existing code that replies on it's current could be viewed as relying on a bug.

I'd be happy to attempt a patch if it's worthwhile preparing one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12643>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:48:12 2011
From: report at bugs.python.org (junior1971)
Date: Wed, 27 Jul 2011 12:48:12 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1311770892.39.0.521874104791.issue12029@psf.upfronthosting.co.za>


Changes by junior1971 <junior1971 at meta.ua>:


Added file: http://bugs.python.org/file22772/generictramadolhclonline.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:48:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jul 2011 12:48:16 +0000
Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311770896.34.0.506118920695.issue12643@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If it's not possible for InteractiveConsole to allow exceptions
> to propagate through sys.excepthook.

Ok, I was not sure that I understood correctly. This change should be an option to not break existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12643>
_______________________________________

From report at bugs.python.org  Wed Jul 27 14:56:39 2011
From: report at bugs.python.org (aliles)
Date: Wed, 27 Jul 2011 12:56:39 +0000
Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311771399.04.0.290503583391.issue12643@psf.upfronthosting.co.za>


aliles <aaron.iles at gmail.com> added the comment:

Yes. I have code that behaves differently under CPython and PyPy because of this issue.

Admittedly that code is somewhat evil. It's attached for reference, in particular the __HelpSyntax class.

----------
Added file: http://bugs.python.org/file22773/startup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12643>
_______________________________________

From report at bugs.python.org  Wed Jul 27 15:33:59 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 27 Jul 2011 13:33:59 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311773639.94.0.0567604751238.issue12641@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Jul 27 16:29:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 14:29:14 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The 'a' conversion type isn't documented in library/stdtypes.rst

----------
assignee: eli.bendersky
components: Documentation
keywords: gsoc
messages: 141228
nosy: eli.bendersky
priority: low
severity: normal
status: open
title: document the "%a" conversion in the old string formatting operations
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Wed Jul 27 16:42:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jul 2011 14:42:26 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311777746.85.0.446312070778.issue12644@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy, patch -gsoc
stage:  -> patch review
Added file: http://bugs.python.org/file22774/issue12644.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Wed Jul 27 16:44:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 14:44:34 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311777874.39.0.283888379616.issue12644@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Wed Jul 27 16:45:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 14:45:46 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311777946.05.0.139054393774.issue12644@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t think anyone could find anything wrong with the patch.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:03:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:03:49 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311779029.83.0.190115591952.issue12641@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi!  Thanks for the report.  This can?t be fixed in 2.5, 2.6 or 3.1, which are in security-fix only mode, but we can do something for the active branches.

A quick web search finds reference of this deprecation/removal as far as 2007.  Does anyone have more official documentation?  If we can find the first gcc version that deprecates this option, then I?ll be able to make a patch with a version check (in order not to change previously working code).

(In the future, it would be nice of you not to use URL obfuscators or pastebins. Such services offer no guarantee of continued availability of hosted resources or links, but it is useful to keep information on this bug tracker for future reference.  Thank you.

The first link is this: http://hg.python.org/cpython/file/4feb889d3bed/Lib/distutils/cygwinccompiler.py#l296
The second: http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-op
The compile log from the third link is attached as a file.)

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis
type: compile error -> behavior
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22775/pastie-2274486

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:07:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:07:45 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311779265.94.0.706961030331.issue12641@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I forgot to answer this:

> Why is -mno-cygwin still be used,
Simply because distutils had no dedicated maintainer for a long time, and because nobody was aware of this change.  I don?t think any Python core developer is using Cygwin.

> and is there any reason why it can't be removed?
For distutils, we have to work on eggshells when fixing bugs to make sure we don?t break third-party code that relies on known bugs or works around them.  That?s why I propose adding a version check* instead of just removing the option.

* i.e. removing -mno-cygwin if self.gcc_version >= some version

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:08:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:08:10 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1311779290.32.0.128269511361.issue12029@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22770/cheapcodfedextramadolvery.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:08:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:08:12 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1311779292.16.0.182625955349.issue12029@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22772/generictramadolhclonline.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:12:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:12:07 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311779527.62.0.34688829476.issue670664@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ezio wrote:
  >>> myhp.feed('<script><p>foo</p></script>')
  data: '<p>foo'  # where's the </p>?

http://www.w3.org/TR/html4/types#type-cdata says:
  Although the STYLE and SCRIPT elements use CDATA for their data
  model, for these elements, CDATA must be handled differently by user
  agents. Markup and entities must be treated as raw text and passed to
  the application as is. The first occurrence of the character sequence
  "</" (end-tag open delimiter) is treated as terminating the end of
  the element's content. In valid documents, this would be the end tag
  for the element.

So I think the example is invalid (should escape the <), and that HTMLParser is not buggy.

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:12:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:12:36 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311779556.09.0.455052133848.issue12614@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22776/fbf2f56d225f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:24:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:24:21 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311780261.87.0.563204336255.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The patch is a little more intrusive than the Python 3 patch because
> Python 2.7 doesn't allow specifying the newline to use when writing a
> file (afaict)

Instead of writing a new class, what about using io.open instead of the builtin?  Then you?ll be able to use the same patch than 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:26:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:26:16 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311780376.35.0.124448343165.issue9968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> where does the 1ko barrier come from? Was it only chosen out of
> performance considerations [...]

Most certainly.  I?ll look at the history of the file later to try to find the developer who decided that.

> tempfile.NamedTemporaryFile was already used in python 3 (fixed in
> r57595, with not many explanations though).

That?s a TemporaryFile, without a name.  For more explanations, follow the parents of the changeset and you?ll find aee21e0c9a70 (referencing #1033) and cbd50ece3b61, where you can see an XXX note that is probably the ?wish? referred to in the cryptic commit message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:35:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 15:35:14 +0000
Subject: [issue12614] Allow to explicitly set the method of
	urllib.request.Request
In-Reply-To: <1311357087.35.0.723496130819.issue12614@psf.upfronthosting.co.za>
Message-ID: <1311780914.21.0.832774932829.issue12614@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Apart from one change (testing for ?self._request is not None?), the patch is ready.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12614>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:37:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 15:37:29 +0000
Subject: [issue12621] Errors in docstrings of find and rfind methods of bytes
	and bytestring
In-Reply-To: <1311445360.36.0.0968747476875.issue12621@psf.upfronthosting.co.za>
Message-ID: <E1Qm6Ap-0008QH-Mb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c3aebd01a033 by Senthil Kumaran in branch '3.2':
Fix closes Issue12621 - Fix docstrings of find and rfind methods of bytes/bytearry/unicodeobject.
http://hg.python.org/cpython/rev/c3aebd01a033

New changeset 842494d73f69 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes Issue12621 - Fix docstrings of find and rfind methods of bytes/bytearry/unicodeobject.
http://hg.python.org/cpython/rev/842494d73f69

New changeset e266415cf42c by Senthil Kumaran in branch '2.7':
merge from 3.2 - Fix closes Issue12621 - Fix docstrings of find and rfind methods of bytes/bytearry/unicodeobject.
http://hg.python.org/cpython/rev/e266415cf42c

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12621>
_______________________________________

From report at bugs.python.org  Wed Jul 27 17:44:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Jul 2011 15:44:50 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311781490.21.0.902727322411.issue670664@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's not buggy, but it is also not helpful.  This kind of thing is what we introduced the 'strict' parameter for.  And indeed I believe we've fixed some of these cases thereby.  So any additional fixes should go into non-strict mode in Python3.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:03:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jul 2011 16:03:14 +0000
Subject: [issue1724822] provide a shlex.split alternative for Windows shell
	syntax
Message-ID: <1311782594.2.0.0858768371239.issue1724822@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> But surely it's not named "POSIX mode" for no reason. It's because
> those rules resemble those of the UNIX shell. While "non-POSIX mode"
> resemble those of non-POSIX shells, such as DOS.

Not exactly: when it comes to parsing, shells on POSIX systems don?t always follow the POSIX rules.  The non-POSIX/POSIX modes in shlex mimic that.

In #9723, it was agreed to move the undocumented pipes.quote function into the shlex module.  I think we could move list2commandline from subprocess into shlex too (that?s probably another report, but I?m saying it here because Philip mentioned it), and also provide a Windows-compliant split function in shlex.

----------
nosy: +eric.araujo, ianbicking, janssen, pmoore, titus
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1724822>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:16:29 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 27 Jul 2011 16:16:29 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1311780261.87.0.563204336255.issue10639@psf.upfronthosting.co.za>
Message-ID: <A2A66F57550F50449EC38E10458E27FF1314F058D9@VA3DIAXVS381.RED001.local>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> Instead of writing a new class, what about using io.open instead of the
> builtin?  Then you?ll be able to use the same patch than 3.2.

Ooh. Excellent suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:43:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 16:43:51 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1311761768.18.0.485230897229.issue12464@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0_8Frx=HtOdsYbcZkg-80sLBLR6v07yyBa1pz3xZv9yQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:44:39 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 16:44:39 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
	failure: BrokenBarrierError
In-Reply-To: <1311626611.98.0.080557357759.issue11871@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1rAPgDCS+a2cvq4fTkf_M-JZVqe6PjkZe9JnzaZuy+Uw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Victor, can I commit it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11871>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:53:53 2011
From: report at bugs.python.org (Matt Basta)
Date: Wed, 27 Jul 2011 16:53:53 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311785633.2.0.721784130542.issue670664@psf.upfronthosting.co.za>


Matt Basta <bastawhiz at gmail.com> added the comment:

> So I think the example is invalid (should escape the <), and that HTMLParser is not buggy.

On the other hand, the HTML5 spec clearly dictates otherwise:

http://www.w3.org/TR/html5/syntax.html#cdata-rcdata-restrictions
The text in raw text and RCDATA elements must not contain any occurrences of the string "</" (U+003C LESS-THAN SIGN, U+002F SOLIDUS) followed by characters that case-insensitively match the tag name of the element followed by one of U+0009 CHARACTER TABULATION (tab), U+000A LINE FEED (LF), U+000C FORM FEED (FF), U+000D CARRIAGE RETURN (CR), U+0020 SPACE, U+003E GREATER-THAN SIGN (>), or U+002F SOLIDUS (/).


Additionally, no browsers (perhaps unless they are in quirks mode) currently obey the HTML4 variant of the rule. This is due largely in part to the need to include strings such as "</scr" + "ipt>" within a script tag itself. This behavior can be observed firsthand by loading this snippet in a browser:

<script><span></span>This should not be visible.</script>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:54:57 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 16:54:57 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311785697.41.0.258833357548.issue12644@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

%r has note (5) saying "The precision determines the maximal number of characters used."

Does this apply to %a as well?

Other than that, LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:55:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 16:55:57 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <E1Qm7Om-0006vD-JV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6119440bae30 by Ross Lagerwall in branch '2.7':
Issue #12607: In subprocess, fix issue where if stdin, stdout or stderr is
http://hg.python.org/cpython/rev/6119440bae30

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Wed Jul 27 18:57:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jul 2011 16:57:01 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311785821.17.0.553451151178.issue12644@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

ISTM that it applies to both %s and %a, but the note is wrong/imprecise.

The precision determines where the string is truncated, but the actual number of characters is given by the field width.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:08:32 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 17:08:32 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311786512.26.0.0868134897043.issue12644@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Yeah, the note should probably be clarified to mention that if precision is specified, only the first precision characters will be shown. The field width is covered globally (for all conversion types) in note 4 above the table.

While we're at it, note 5 is:

   Precision (optional), given as a '.' (dot) followed by the precision. If specified as '*' (an asterisk), the actual width is read from the next element of the tuple in values, and the value to convert comes after the precision.

I think that the second sentence should have "the actual precision" instead "the actual width".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:23:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 17:23:21 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <E1Qm7pF-0001In-N5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0f09b7f90060 by Eli Bendersky in branch 'default':
Issue #11049: added test_support to regrtest.STDTESTS list
http://hg.python.org/cpython/rev/0f09b7f90060

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:28:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Jul 2011 17:28:50 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311787730.28.0.361127719914.issue670664@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, but we don't claim to support HTML5 yet.

The best way to support HTML5 is probably a topic for python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:34:01 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Jul 2011 17:34:01 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311788041.84.0.235879717599.issue12576@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Re-opening, as I think this needs to still be applied to Python 2.7.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:36:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 17:36:37 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <E1Qm828-0002PA-DJ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2229b0422369 by Charles-Fran?ois Natali in branch '2.7':
- Issue #12603: Fix pydoc.synopsis() on files with non-negative st_mtime.
http://hg.python.org/cpython/rev/2229b0422369

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:39:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 17:39:49 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <E1Qm85D-0002Xb-PX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2bc740a83010 by Charles-Fran?ois Natali in branch '3.2':
Issue #12603: Fix pydoc.synopsis() on files with non-negative st_mtime.
http://hg.python.org/cpython/rev/2bc740a83010

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:41:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 17:41:30 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <E1Qm86r-0002mS-Gv@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5f003d725619 by Charles-Fran?ois Natali in branch 'default':
Issue #12603: Fix pydoc.synopsis() on files with non-negative st_mtime.
http://hg.python.org/cpython/rev/5f003d725619

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:48:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 17:48:36 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311788916.22.0.912495449516.issue12380@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Looks good. How about also adding some tests for the original request of supporting bytearrays in ljust/rjust/center?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Wed Jul 27 19:57:24 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Jul 2011 17:57:24 +0000
Subject: [issue12576] urlib.request fails to open some sites
In-Reply-To: <1310861264.06.0.891924584954.issue12576@psf.upfronthosting.co.za>
Message-ID: <1311789444.03.0.781679032683.issue12576@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Never mind.  This changeset got applied to 2.7 (thanks!) but didn't get linked in the tracker.


changeset:   71523:b66bbbdc7abd
branch:      2.7
parent:      71518:73ae3729b8fe
user:        Senthil Kumaran <senthil at uthcode.com>
date:        Wed Jul 27 09:37:17 2011 +0800
summary:     merge from 3.2 - fix urlopen behavior on sites which do not send (or obsfuscates) Connection: Close header.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12576>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:03:35 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Jul 2011 18:03:35 +0000
Subject: [issue12645] test.support. import_fresh_module - incorrect doc
In-Reply-To: <1311789815.76.0.639942891335.issue12645@psf.upfronthosting.co.za>
Message-ID: <1311789815.76.0.639942891335.issue12645@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

>From Ezio Melotti's email to python-dev:


    diff --git a/Doc/library/test.rst b/Doc/library/test.rst
    --- a/Doc/library/test.rst
    +++ b/Doc/library/test.rst
    @@ -447,7 +447,7 @@
        Module and package deprecation messages are suppressed during this import
        if *deprecated* is ``True``.

    -   This function will raise :exc:`unittest.SkipTest` is the named module
    +   This function will raise :exc:`unittest.SkipTest` if the named module


Actually I think this is no longer true.  import_fresh_module raises an ImportError if *name* can't be imported, or returns None if the fresh module is not found.

Its use case is to enable or block accelerations for modules that optionally provide one.  All the modules that currently use import_fresh_module are (afaik) always available (json, warnings, heapq), so raising SkipTest when the module is missing is not useful now.
It returns None in the case an acceleration is missing, so e.g. in "cjson = import_fresh_module('json', fresh=['_json'])" cjson will be None and it will be possible to do things like @skipUnless(cjson, 'requires _json').  Here raising an ImportError will defeat (part of) the purpose of the function, i.e. avoiding:
try:
 import _json
except ImportError:
 _json = None

and raising a SkipTest when the accelerations are missing is not an option if there are other tests (e.g. the tests for the Python implementation).

These changes come from http://hg.python.org/cpython/rev/c1a12a308c5b .  Before the change import_fresh_module was still returning the module (e.g. json) even when the acceleration (fresh=['_json']) was missing, and the C tests were run twice using the same pure-python module used for the Py ones.

The typo and the wrong doc is also on 2.7.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141255
nosy: docs at python, eli.bendersky, ezio.melotti
priority: normal
severity: normal
status: open
title: test.support. import_fresh_module - incorrect doc
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12645>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:24:10 2011
From: report at bugs.python.org (Piotr Zolnierczuk)
Date: Wed, 27 Jul 2011 18:24:10 +0000
Subject: [issue2733] mmap resize fails on anonymous memory
In-Reply-To: <1209661457.64.0.989081565875.issue2733@psf.upfronthosting.co.za>
Message-ID: <1311791050.77.0.69982216102.issue2733@psf.upfronthosting.co.za>


Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com> added the comment:

I wonder if this is related to the problem I reported about two weeks ago
http://bugs.python.org/issue12562?

----------
nosy: +zolnie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2733>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:29:22 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Wed, 27 Jul 2011 18:29:22 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>


New submission from Oleg Oshmyan <chortos at inbox.lv>:

If a truncated input stream is given to the zlib.decompress function, it raises a zlib.error. However, if the same stream is fed to a zlib.Decompress object, no exception is raised during the entire lifetime of the object. Attached is an example demonstrating the discrepancy.

zlib.decompress raises this exception when it gets a Z_BUF_ERROR from zlib, while the implementation of zlib.Decompress.decompress just skips every Z_BUF_ERROR it gets as described in this (apparently inaccurate) comment:
        /* We will only get Z_BUF_ERROR if the output buffer was full
           but there wasn't more output when we tried again, so it is
           not an error condition.
        */

----------
components: Extension Modules
files: zlib-fail.py
messages: 141257
nosy: chortos
priority: normal
severity: normal
status: open
title: zlib.Decompress.decompress/flush do not raise any exceptions when given truncated input streams
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22777/zlib-fail.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12646>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:33:34 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 18:33:34 +0000
Subject: [issue12595] python.h redundant redeclarations
In-Reply-To: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>
Message-ID: <1311791614.4.0.58470946696.issue12595@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a partial patch for from issue 8914 that should deal with this issue in 3.2.

----------
keywords: +patch
Added file: http://bugs.python.org/file22778/issue12595.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12595>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:35:11 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 18:35:11 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1311791711.77.0.673908722031.issue8914@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Regarding issue 12595 (function redeclaration warning when including Python.h), could a small part (or optionally all) of this patch be backported to 3.2?

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:37:45 2011
From: report at bugs.python.org (Matt Basta)
Date: Wed, 27 Jul 2011 18:37:45 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311791865.72.0.675600341619.issue670664@psf.upfronthosting.co.za>


Matt Basta <bastawhiz at gmail.com> added the comment:

> Yes, but we don't claim to support HTML5 yet.

There's also no claim in the docs or the source that HTMLParser specifically adheres to HTML4, either.

Ideally, the parser should strive for parity with the functionality of major web browsers, as they are the de-facto standard for HTML parser behavior. All of the browsers on my machine, for instance, will even parse the following snippet with the behavior described in the HTML5 spec:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<script><span></span>This should not be visible.</script>


Even in pre-HTML5 browsers, this is the way that HTML gets parsed. For the heck of it, I downloaded an old copy of Firefox 2.0 and ran the above snippet. The behavior is consistent.

While I would otherwise agree that keeping to the HTML4 spec is the right thing to do, this is a quirk of the spec that is not only ignored by browsers (as can be seen in FX2) and changed in a future version of the spec, but is causing problems for a good number of developers.

It could be argued that the patch is a far more elegant solution for Beautiful Soup developers than the workaround in msg88864.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:41:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 18:41:10 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <E1Qm92b-0008Nq-6t@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f9cf55bbe9b9 by Jason R. Coombs in branch '2.7':
Fixes #10639: reindent.py should not convert newlines
http://hg.python.org/cpython/rev/f9cf55bbe9b9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:42:24 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 27 Jul 2011 18:42:24 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311792144.45.0.577824274063.issue10639@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:42:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Jul 2011 18:42:42 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1311792162.55.0.423585372264.issue1813@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm seeing this test failure in Gentoo, as well.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:50:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jul 2011 18:50:23 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
	failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1311792623.72.0.445769503504.issue11871@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

YES YOU CAN

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11871>
_______________________________________

From report at bugs.python.org  Wed Jul 27 20:54:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 18:54:21 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311792861.34.0.930992996223.issue12380@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Updated the patch to add tests for {bytes,bytearray}.{center,ljust,rjust}. The tests check that both bytes and bytearray are always accepted as the fill character.

----------
Added file: http://bugs.python.org/file22779/c_format_bytearray_plus_additional_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:00:51 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Jul 2011 19:00:51 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1311793251.16.0.59506448728.issue12646@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12646>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:03:31 2011
From: report at bugs.python.org (Ruben Van Boxem)
Date: Wed, 27 Jul 2011 19:03:31 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311793411.22.0.656977429656.issue12641@psf.upfronthosting.co.za>


Ruben Van Boxem <vanboxem.ruben at gmail.com> added the comment:

> Does anyone have more official documentation? 

The commit I  linked to has the full option removal at October 7 2010 (see the fifth item in the changelog entry). Any GCC (major) version released after that will have it completely removed.

Deprecation happened (according to the first doc change mentioning this option as being deprecated) on 2009-03-25: http://repo.or.cz/w/official-gcc.git/commit/6609be22531f447aeddbb3f670ad7883036cb23f

It looks like GCC 4.4 and up have this change in them, by looking at their commit logs. Anyone using GCC 4.3 on MinGW should be shot (but that's just my humble opinion, rather radical I admit ;-) )

Note this has really nothing to do with current Cygwin or the cygwin platform; MinGW was part of the Cygwin source for a long time, and every MinGW compiler was burdened to search the Cygwin header and lib paths. These commits fixed that problem.

MinGW(-w64) is a native compiler for Win32 just as MSVC is. Links to msvcrt.dll and has no POSIX translation/compatibility layer like the Cygwin DLL.

May I ask for a reconsideration to commit a fix for this for Python 2.7 at least? With the version check it doesn't hurt anyone, instead it helps prevent further confusion and support requests on the MinGW side. Distutils pop up everywhere, and the projects depending on them rely on them working correctly. Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:13:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Jul 2011 19:13:09 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311793989.53.0.421914604186.issue670664@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I thought HTLM4 conformance was documented somewhere, but I could be wrong.

HTML5, from what I understand (I haven't read the spec), is explicitly or implicitly following "what browsers really do" exactly because nobody conformed to HTML4, so arguing that "a later spec changed the rules" isn't really relevant in this case :)

We made the change the way we did (strict option) out of backward compatibility concerns, so I still think this topic needs to be discussed on python-dev.  I think the argument that python should handle what most browsers handle is a strong one (I myself would have been in favor of just making this stuff work, absent backward compatibility concerns).  The question in my mind is what's the best way to get there from here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:15:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 19:15:20 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1311794120.76.0.521052869754.issue5113@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch attached.

----------
keywords: +needs review, patch
stage:  -> patch review
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22780/chown_hpux.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:16:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 19:16:31 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311794191.36.0.679379394222.issue12603@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed.
Josh, thanks for the report.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:17:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 19:17:46 +0000
Subject: [issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0
In-Reply-To: <1311280391.94.0.571188388286.issue12603@psf.upfronthosting.co.za>
Message-ID: <1311794266.11.0.704344869212.issue12603@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12603>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:23:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jul 2011 19:23:02 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1311794582.73.0.357845804026.issue12170@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/issue12170>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:26:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jul 2011 19:26:00 +0000
Subject: [issue12636] IDLE ignores -*- coding -*- with -r option
In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>
Message-ID: <1311794760.15.0.551381561415.issue12636@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/issue12636>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:26:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jul 2011 19:26:16 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently bool(None) returns False only because it has a special case in PyObject_IsTrue().   All other types can become False only if they implement __bool__() or __len__().

I propose removing the special case branch and instead adding __bool__ to None.  This will simplify the explanation of what bool() does to:  "bool(x) always returns True unless the object defines __bool__() to return False or defines __len__() to return a non-zero value".

The removal of the special case will slightly slow down tests for "if None", and it will slightly speed-up tests for "if x" where x is something other than True, False, or None.

----------
assignee: rhettinger
components: Interpreter Core
messages: 141269
nosy: rhettinger
priority: low
severity: normal
status: open
title: Add __bool__ to None
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:28:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Jul 2011 19:28:03 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
	failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <E1Qm9lw-00041B-BA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aa9c0fdf2143 by Charles-Fran?ois Natali in branch '3.2':
Issue #11871: In test_threading.BarrierTests, bump the default barrier timeout
http://hg.python.org/cpython/rev/aa9c0fdf2143

New changeset e8da570d29a8 by Charles-Fran?ois Natali in branch 'default':
Issue #11871: In test_threading.BarrierTests, bump the default barrier timeout
http://hg.python.org/cpython/rev/e8da570d29a8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11871>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:40:32 2011
From: report at bugs.python.org (Jon)
Date: Wed, 27 Jul 2011 19:40:32 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311795632.35.0.626960760466.issue12641@psf.upfronthosting.co.za>


Jon <jon.forums at gmail.com> added the comment:

I have confirmed on Win7 that the following 32bit MinGW flavors still recognize -mno-cygwin option and build without error:

(4.5.2) http://tdm-gcc.tdragon.net/download

(4.5.4) http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/ using the mingw-w32-1.0-bin_i686-mingw_20110624.zip download

...by compiling with:

[i686-w64-mingw32-]gcc -Wall -mno-cygwin -o helloworld.exe helloworld.c

...where helloworld.c was:

#include <stdio.h>
int main(int argc, char *argv[]) { printf("Hello World!\n"); return 0; }


I have not yet checked the latest mingw.org download from the following, but I expect that it also recognizes -mno-cygwin. I will check later and report back if appropriate.

(4.5.2) http://sourceforge.net/projects/mingw/files/

Given Ruben's 4.4 comment, something is odd here. Looks like some gcc source spelunking as these doc links make no mention of the removal:

http://gcc.gnu.org/gcc-4.6/changes.html
http://gcc.gnu.org/gcc-4.5/changes.html
http://gcc.gnu.org/gcc-4.4/changes.html

and the gcc manual is inconsistent. This summary mentions the option

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Option-Summary.html#Option-Summary

but the details sections don't mention the option

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/i386-and-x86_002d64-Windows-Options.html#i386-and-x86_002d64-Windows-Options

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Ah, our good friend grep.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:42:51 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 27 Jul 2011 19:42:51 +0000
Subject: [issue12607] subprocess(stdout=...,
	stderr=sys.stdout) breaks stderr for child
In-Reply-To: <1311327985.38.0.34086664076.issue12607@psf.upfronthosting.co.za>
Message-ID: <1311795771.88.0.061625940185.issue12607@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
assignee:  -> rosslagerwall
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12607>
_______________________________________

From report at bugs.python.org  Wed Jul 27 21:56:51 2011
From: report at bugs.python.org (phep)
Date: Wed, 27 Jul 2011 19:56:51 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311796611.63.0.750499865211.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

>> where does the 1ko barrier come from? Was it only chosen out of 
>> performance considerations [...]
> 
> Most certainly.  I?ll look at the history of the file later to try to
> find the developer who decided that.

Guido van Rossum made the changes. Before that a temporary file was created for every form field.

>> tempfile.NamedTemporaryFile was already used in python 3 (fixed in 
>> r57595, with not many explanations though).
> 
> That?s a TemporaryFile, without a name.  For more explanations, follow

Yes, my sleepy eyes and drowsy brain fooled me more than once last
night. Sigh...

> the parents of the changeset and you?ll find aee21e0c9a70 
> (referencing #1033) and cbd50ece3b61, where you can see an XXX
> note that is probably the ?wish? referred to in the cryptic commit
> message.

Thanks.

A last question before trying to write the patch: In order for the change I propose to be interesting, one should let caller code decide where (on disk) the NamedTemporaryFile should be created since writing this on a different partition than the one the file will eventually reside on would ruin the whole trick. Also, I believe one can think of other reasons to give this freedom.

Unfortunately, in order to do that, I can see no other solution than to change the FieldStorage constructor signature since the temp files are created as soon as the object is instantiated. So, we would end up with something along those lines:

class FieldStorage(cgi.FieldStorage):
    def __init__(self, tempdir=tempfile.gettempdir()):
        self.tempdir = tempdir
	...

or a somewhat more convoluted form that would avoid importing tempfile needlessly.

Do you think this would be acceptable ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Wed Jul 27 22:03:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Jul 2011 20:03:23 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311797003.54.0.856502204583.issue670664@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

IIRC we have been following what browsers do in other cases already.
There were also some discussions about supporting HTML5 (see e.g. #7311 and #11113) and the strict vs non-strict mode introduced in Python3.

Note that changing the way things are parsed is generally not backward-compatible, but you might argue that new behavior is useful enough to break some hackish code that was trying to workaround the limitations of HTMLParser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Wed Jul 27 22:27:24 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 27 Jul 2011 20:27:24 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1311798444.34.0.847899129654.issue12646@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12646>
_______________________________________

From report at bugs.python.org  Wed Jul 27 22:33:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Jul 2011 20:33:05 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311798785.41.0.587165381163.issue12647@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22781/none_bool.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Wed Jul 27 22:35:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 27 Jul 2011 20:35:12 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
	failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1311798912.46.0.968161669558.issue11871@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> YES YOU CAN

:-)

----------
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/issue11871>
_______________________________________

From report at bugs.python.org  Wed Jul 27 23:07:49 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Wed, 27 Jul 2011 21:07:49 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1311800869.27.0.0430628095305.issue12646@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

I believe the attached patch fixes this problem, making zlib.Decompress.flush() raise the exception raised by zlib.decompress().

In the same patch, I also took the opportunity to correct a wrong comment in the implementation of flush() and change the error messages given by zlib.{De,C}ompress.flush() on {in,de}flateEnd() errors to the more end-user-friendly ones given in the same occasions by zlib.{de,}compress(). If this does not sound like a good thing to do, feel free (whoever ends up committing this) to remove these changes.

One uncomfortable issue I see with the patch is that zlib.Decompress.flush() now potentially gives an error message with Z_OK as the error code, but unless I misunderstand the comments in the real zlib?s zlib.h and that never happens (I was unable to produce a situation that would cause this), the only other options are faking another error code and setting an exception message whose format is different from all other exceptions raised by the zlib module.

----------
keywords: +patch
Added file: http://bugs.python.org/file22782/zlib.Decompress.flush.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12646>
_______________________________________

From report at bugs.python.org  Wed Jul 27 23:16:32 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Wed, 27 Jul 2011 21:16:32 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1311801392.22.0.0354686313951.issue12646@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

> faking another error code

Actually, I think another call to inflate(), which would be valid at that point, would just return the other error code, so it can as well be faked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12646>
_______________________________________

From report at bugs.python.org  Wed Jul 27 23:38:19 2011
From: report at bugs.python.org (Jon)
Date: Wed, 27 Jul 2011 21:38:19 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311802699.08.0.520263963462.issue12641@psf.upfronthosting.co.za>


Jon <jon.forums at gmail.com> added the comment:

should the question be "what's the first mingw gcc version that -mno-cygwin usage unnecessary" rather than finding the first version the option was removed?

and, does it matter whether you're building on win for win, or cross compiling for win from nix?

sadly, i don't know gcc internals but a post to the mingw and/or mingw-w64 ml's should get the right people weighing in.

btw, can distutils do a lightweight configure-like check for feature presence rather than going a gcc version check?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Wed Jul 27 23:49:46 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Jul 2011 21:49:46 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1311803386.12.0.689636546093.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't feel comfortable changing what is defined in a header file in a point release, so I am not going to backport the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Thu Jul 28 00:05:41 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Jul 2011 22:05:41 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311804341.53.0.544844771937.issue12647@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

It all sounds good to me. Less magic behind the scenes is good.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 00:25:17 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 27 Jul 2011 22:25:17 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311805517.75.0.812606980065.issue12647@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

And this doesn't impact "if x is None", so +1.

----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 00:27:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jul 2011 22:27:58 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311805678.53.0.34174766395.issue12647@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure why the special case shouldn't be retained. It's obviously there for speed reasons.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 00:36:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Jul 2011 22:36:52 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311806212.18.0.306110928703.issue12647@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm not sure why the special case shouldn't be retained.

We can keep the fast path in PyObject_IsTrue but add a __bool__ method to NoneType.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 00:37:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jul 2011 22:37:30 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311806212.18.0.306110928703.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311806160.3616.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > I'm not sure why the special case shouldn't be retained.
> 
> We can keep the fast path in PyObject_IsTrue but add a __bool__ method to NoneType.

That's what I meant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 09:47:21 2011
From: report at bugs.python.org (Jorgen Skancke)
Date: Thu, 28 Jul 2011 07:47:21 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1311839241.74.0.975749573056.issue11564@psf.upfronthosting.co.za>


Jorgen Skancke <jorgsk at nt.ntnu.no> added the comment:

I recently ran into this problem when I tried to multiprocess jobs with large objects (3-4 GB). I have plenty of memory for this, but multiprocessing hangs without error, presumably because pickle hangs without error when multiprocessing tries to pickle the object. I can't offer a solution, but I can verify that the limitation in pickle is affecting Python usage.

----------
nosy: +jorgsk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Thu Jul 28 10:11:43 2011
From: report at bugs.python.org (ledave123)
Date: Thu, 28 Jul 2011 08:11:43 +0000
Subject: [issue12636] IDLE ignores -*- coding -*- with -r option
In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>
Message-ID: <1311840703.02.0.220619990678.issue12636@psf.upfronthosting.co.za>


ledave123 <ledave123 at yahoo.fr> added the comment:

The problem can be fixed with tokenize :
I'm sorry I never submitted a path and I have no access to the source tree from here, if someone cares to do it, do not hesitate.

    def execfile(self, filename, source=None):
        "Execute an existing file"
        if source is None:
            import tokenize
            source = tokenize.open(filename).read()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12636>
_______________________________________

From report at bugs.python.org  Thu Jul 28 10:26:11 2011
From: report at bugs.python.org (Nir Aides)
Date: Thu, 28 Jul 2011 08:26:11 +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: <1311841571.44.0.239068288852.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Hi Gregory,

> Gregory P. Smith <greg at krypto.org> added the comment:
> No Python thread is ever fork safe because the Python interpreter itself can never be made fork safe. 
> Nor should anyone try to make the interpreter itself safe. It is too complex and effectively impossible to guarantee.

a) I think the term "Guarantee" is not meaningful here since the interpreter is probably too complex to guarantee it does not contain other serious problems.
b) If no Python thread is ever fork safe, can you illustrate how a trivial Python thread spinning endlessly might deadlock a child forked by another Python thread?

I was not able to find reports of deadlocks clearly related to multiprocessing worker threads so they could be practically safe already, to the point other Python-Dev developers would be inclined to bury this as a theoretical problem :)

Anyway, there exists at least the problem of forking from the pool worker thread and possibly other issues, so the code should be reviewed.
Another latent problem is multiprocessing logging which is disabled by default?


> There is no general solution to this, fork and threading is simply broken in POSIX and no amount of duct tape outside of the OS kernel can fix it. 

This is why we should "sanitize" the multithreading module and deprecate mixing of threading and multiprocessing. 
I bet most developers using Python are not even aware of this problem. 
We should make sure they are through documentation.

Here is another way to look at the current situation:

1) Don't use threading for concurrency because of the GIL.
2) Don't mix threading with multiprocessing because threading and forking don't mix well.
3) Don't use multiprocessing because it can deadlock.

We should make sure developers are aware of (2) and can use (3) safely***.


> My only desire is that we attempt to do the right thing when possible with the locks we know about within the standard library.

Right, with an atfork() mechanism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Jul 28 10:28:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jul 2011 08:28:52 +0000
Subject: [issue12636] IDLE ignores -*- coding -*- with -r option
In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>
Message-ID: <1311841732.15.0.0602510014136.issue12636@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Yes, tokenize.open() should fix this issue, but you should close the file after using it. Use for example "with tokenize.open(): ...".

Can you write a patch? You can download the source code using Mercurial or download it manually from http://hg.python.org/cpython/file/tip

See also our http://docs.python.org/devguide/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12636>
_______________________________________

From report at bugs.python.org  Thu Jul 28 11:40:03 2011
From: report at bugs.python.org (kota)
Date: Thu, 28 Jul 2011 09:40:03 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>


New submission from kota <nospam.kotarou.dono at gmail.com>:

There seems to be a wrong import module search order (http://docs.python.org/tutorial/modules.html#the-module-search-path) on Windows. Python seems to be loading the built-in module instead of the python code with the same name as the module in the current directory. This only happens on Windows as I tested on Linux and it loaded the module properly.

Steps to reproduce:
1. Create a file named `parser.py' containing `print "test"'
2. Open a console window to the directory you created the file in and run `python2.7 -v' or `python -v'
3. Type `import parser'

On Windows, I get this output:
import encodings.cp437 # from c:\Python27\lib\encodings\cp437.py
# wrote c:\Python27\lib\encodings\cp437.pyc
import parser # builtin

On Linux, I get this:
import parser # from parser.py
# wrote parser.pyc
test

`sys.path' on Windows:
['', 'C:\\WINDOWS\\system32\\python27.zip', 'c:\\Python27\\DLLs', 'c:\\Python27\\lib', 'c:\\Python27\\lib\\plat-win', 'c:\\Python27\\lib\\lib-tk', 'c:\\Python27', 'c:\\Python27\
\lib\\site-packages']

`sys.path' on Linux:
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/pymodules/python2.7/gtk-2.0', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7']

----------
components: None
messages: 141288
nosy: kota
priority: normal
severity: normal
status: open
title: Wrong import module search order on Windows
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12648>
_______________________________________

From report at bugs.python.org  Thu Jul 28 12:58:50 2011
From: report at bugs.python.org (Neil Aspinall)
Date: Thu, 28 Jul 2011 10:58:50 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1311850730.42.0.191797519202.issue3605@psf.upfronthosting.co.za>


Neil Aspinall <mail at neilaspinall.co.uk> added the comment:

Would it be possible for this issue's fix (PyErr_Occurred() returning null when the thread state is null) to be applied to the 2.7 branch?

----------
nosy: +naspinal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Thu Jul 28 13:16:29 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 28 Jul 2011 11:16:29 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1311851789.37.0.63418357238.issue3605@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3605>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:15:06 2011
From: report at bugs.python.org (dandre)
Date: Thu, 28 Jul 2011 13:15:06 +0000
Subject: [issue12649] email.Header corupts international email header and
	ignores maxlinelen in some cases
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>


New submission from dandre <andre.d at gmx.net>:

Hello there, first of all, thank you all for Python. I didn't know it was so great; otherwise I'd have checked it out before.

Using 2.7.2 MSC v.1500 32 Intel bit for now.

Playing with email.header, I came across an odd behaviour.

Attached please find a script which demonstrates that
1) maxlinelen is ignored and
2) header fields are split in a manner not suitable for all systems involved in email processing.

The script will print the headers. They're all the same and extend over two lines; both should probably not be the case, although it dosn't hurt in itself.

If you uncomment the SMTP part of the script and send that email to yourself, you'll probably see that the From: and To: header will be misinterpreted by your email client; I tested this with two different email providers. Looking at the raw data which are received, it appears that at least in one case, a system along the way added a comma between the two "To:" lines. This is something which one should easily be able to avoid, if only the maxlinelen would be obeyed...

Having taken a look at email.header.py, it appears to me that the semantics of _encode_chunks() does not exactly match its documentation due to the results of (at least some) charset.header_encode() calls. What seems to happen is that charset.header_encode() can return several lines already, and it will apparently split the line without any deeper knowledge. As a result, the Header module will not apply its sophisticated maxlinelen/splitchars logic. The header is split at some pretty arbitrary point and not all systems appear to be happy with that, although the relevant RFC apparently only reads "SHOULD" in this regard.

----------
components: Library (Lib)
files: email_header_bug.py
messages: 141290
nosy: dandre
priority: normal
severity: normal
status: open
title: email.Header corupts international email header and ignores maxlinelen in some cases
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22783/email_header_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:43:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Jul 2011 13:43:25 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311860605.22.0.115189242851.issue670664@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

HTML5 being a spec that builds on HTML 4.01 and real-world ways to deal with non-compliant input, I don?t object to fixes that follow the HTML5 spec.  Regarding backward compatibility, we can break it if we decide that the behavior we?re changing was a bug.  I think it?s far more useful to support BeautifoulSoup than to retain a non-useful behavior forever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:44:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Jul 2011 13:44:21 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311860661.8.0.402191110965.issue10639@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:49:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Jul 2011 13:49:16 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311860956.51.0.195052047195.issue9968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>>> where does the 1ko barrier come from? Was it only chosen out of 
>>> performance considerations [...]
>> Most certainly.  I?ll look at the history of the file later to try to
>> find the developer who decided that.
> Guido van Rossum made the changes. Before that a temporary file was
> created for every form field.

Do you have the changeset ID?

> A last question [...]

For a new feature, it?s okay to change signatures.  Backward compatibility is preserved by appending the new argument at the end of the arguments lists, and making it optional.

Given that tempfile respects the TMP and TMPDIR environment variables, do you think it would be possible for users to control the download dir for uploaded files by editing os.environ?  This would require no change to cgi.  If that?s not possible, then we?ll have to change the FieldStorage class.

> Also, I believe one can think of other reasons to give this freedom.

Can you think about some of them?

>    def __init__(self, tempdir=tempfile.gettempdir()):
> or a somewhat more convoluted form that would avoid importing
> tempfile needlessly.

You could probably have a None argument that would be passed down to tempfile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:57:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 13:57:00 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311861420.91.0.260613508941.issue12649@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are using Header incorrectly.  It should look more like this:

    th = _e_header.Header(maxlinelen=200, header_name='To')
    th.append(tfc[:-1])
    th.append(wtc[:-1], charset='utf-8')
    th.append(tem)


This results in:

  To: ABCDEFGH =?utf-8?b?0ILYgeC5hOC8kuGPiuGauw==?= <abcdefg at hijk-lmnopqr.st>

Which is valid per RFC, which encoding the address is not.  A compliant mailer should be able to handle the Subject line from your version correctly, but not the To or From lines.

The fact that you don't want the trailing spaces is an artifact of the API.  Using this API requires more knowledge of the RFCs than anyone should want to have.  In Python 3.3 we will be introducing a new API in the email package that will make all of this *much* simpler.

The maxlinelen issue does appear to be a bug, though.

----------
keywords: +easy
nosy: +r.david.murray
title: email.Header corupts international email header and ignores maxlinelen in some cases -> email.Header ignores maxlinelen when wrapping encoded words
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:57:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Jul 2011 13:57:17 +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: <1311861437.86.0.559154011263.issue10968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve committed the cleanup to my 3.3 clone and will push this week.

Here?s a doc patch.  Before my patch, the various classes were documented in two parts: one entry with the factory function (e.g. Thread), without index reference, and one section (e.g. ?Thread Objects?), which used a class directive (and thus index target) for most but not all classes.

After my patch, all classes are documented with a class directive, in their section (i.e. ?Thread Objects?), with a versionchanged note informing that the name used to be that of a factory function.  The only remaining glitch is that the ?X Objects? sections start with a description of the class? use, which references methods with constructs like :meth:`run`, which cannot be turned into links as Sphinx lacks context: the class directive only happens after.  I could move the class directives right after the heading (?X Objects?), so that the meth roles get turned into links.

----------
assignee:  -> eric.araujo
Added file: http://bugs.python.org/file22784/threading-3.3-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:57:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 13:57:56 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311861476.32.0.490266863935.issue12649@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/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 15:59:00 2011
From: report at bugs.python.org (gabriele.trombetti)
Date: Thu, 28 Jul 2011 13:59:00 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>


New submission from gabriele.trombetti <g.trombetti at plasmacore.com>:

There seems to be a file descriptor (fd) leak in subprocess upon call to kill() and then destroying the current subprocess object (e.g. by scope exit) if the pipe functionality is being used.

This is a reproducer:

(Linux 2.6.25, Python 2.7.1 (r271:86832))

import subprocess, time
def leaktest():
    subp = subprocess.Popen("echo hi; sleep 200; echo bye", shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    #you can do something here
    subp.terminate()
    #subp.wait() #Fixes the bug
    #time.sleep(0.001) #fixes the bug
    #time.sleep(0.0000001) #doesn't fix the bug
    return True

Launch the function multiple times interactively, each time the number of open file descriptors for the python process will increase by 2. You can see that by "ls -l /proc/<pid>/fd"
This seems to be a race condition because adding a time.sleep(0.001) before the return fixes the problem. Probably some kernel delay is responsible for the race. 

This bug is significant for daemons because the daemon will die once the number of open file descriptors hits the ulimit, usually 1024, so please fix. 

Note: until the bug is fixed, a simple workaround (not documented in module docs though) is to call Popen.wait() after Popen.kill()

Thank you

----------
components: Library (Lib)
messages: 141295
nosy: gabriele.trombetti
priority: normal
severity: normal
status: open
title: Subprocess leaks fd upon kill()
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:12:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Jul 2011 14:12:25 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311862345.22.0.830702926813.issue12641@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> May I ask for a reconsideration to commit a fix for this for Python
> 2.7 at least? With the version check it doesn't hurt anyone
There?s a misunderstanding: I explained why 2.5, 2.6 and 3.1 can?t be fixed, but if you look at the versions at the top of this page, you?ll see 2.7, 3.2 and 3.3 listed.  This will get fixed in these versions.

> Ah, our good friend grep.
Thanks for the exploration.  This looks complicated.

> should the question be "what's the first mingw gcc version that
> -mno-cygwin usage unnecessary" rather than finding the first version
> the option was removed?
If removing the option in these versions causes no change (i.e. doesn?t break any code), I agree.

> and, does it matter whether you're building on win for win, or cross
> compiling for win from nix?
I?m afraid I don?t know enough about Windows and MinGW to answer that.  If we can?t be sure about versions and consequences here, I?ll go to the MinGW ML.

> btw, can distutils do a lightweight configure-like check for feature
> presence rather than going a gcc version check?
There is a config command that?s not very used, but it would be IMO overkill to use it in the compiler code.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:13:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 14:13:45 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1311862425.83.0.688557626557.issue12650@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:16:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 14:16:12 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311862572.8.0.982284422706.issue670664@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless someone else has picked it up, BeautifulSoup is a no longer an issue since its author has abandoned it.  That doesn't change the fact that IMO it would be nice for our library to handle input generously.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:16:58 2011
From: report at bugs.python.org (dandre)
Date: Thu, 28 Jul 2011 14:16:58 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311862618.94.0.976298130654.issue12649@psf.upfronthosting.co.za>


dandre <andre.d at gmx.net> added the comment:

Thank you for pointing out my wrong usage of Header.

Does this mean I should call Header.append() for each token, with tokens being separated by WS, or probably rather COMMASPACE in the case of To:? Or does it mean I should call Header.append() for each "logical" token of From: and To:, let's say, for the two parts returned by email.utils.parseaddr()?

Please excuse me if this is not the right place to discuss this, but I'm unaware of any place on the Web wehre these questions are addressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:20:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 14:20:16 +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: <1311862816.92.0.962376732835.issue10968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You ought to be able to use either a context directive (I forget its name and syntax), or the full reference syntax (:meth:`~threading.Thread.run`) to make those links work without moving things around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:24:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Jul 2011 14:24:42 +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: <1311863082.97.0.510841965884.issue10968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> You ought to be able to use either a context directive (I forget its
> name and syntax),

Hm, do you mean something similar to currentmodule?

> or the full reference syntax (:meth:`~threading.Thread.run`) to make
> those links work without moving things around.

Yes, Thread.run would work, but I find that inelegant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:28:44 2011
From: report at bugs.python.org (Jon)
Date: Thu, 28 Jul 2011 14:28:44 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1311863324.63.0.771881941294.issue12641@psf.upfronthosting.co.za>


Jon <jon.forums at gmail.com> added the comment:

>> and, does it matter whether you're building on win for win, or cross
>> compiling for win from nix?
>I?m afraid I don?t know enough about Windows and MinGW to answer that.  If we can?t be sure about versions and consequences here, I?ll go to the MinGW ML.

Ruben's on it :)
http://sourceforge.net/mailarchive/message.php?msg_id=27864860

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Jul 28 16:47:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 14:47:53 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311864473.73.0.668593389722.issue12649@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

They probably ought to be discussed in our docs :(

The only thing that may be encoded in an address is the "display name" (the first part returned by parseaddr).  (Actually the domain name could be IDNA encoded, but we don't support that directly in email.  3.3 will.)  So the easiest way to code this is probably to take a list of parseaddr'ed addresses, and append display_name as utf-8, and the address formatted as '<%s>,' as ascii.  Omitting the comma for the last one, of course.  Not very elegant, but I believe it should work.

If you want to get fancy you can split out the domain and run it through the IDNA codec to encode it before passing it in as part of the ASCII token.

Header puts spaces between ASCII and non-ASCII tokens automatically, so you don't have to add them to either the encoded or unencoded tokens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 17:29:39 2011
From: report at bugs.python.org (dandre)
Date: Thu, 28 Jul 2011 15:29:39 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311866979.15.0.523800971747.issue12649@psf.upfronthosting.co.za>


dandre <andre.d at gmx.net> added the comment:

Thanks again for the clarification.

I may not look like it ;), but my fanciness has to go even further. So, for the sake of completeness, it appears that the world is now up to UTF-8 local parts of email addresses, and punycode for the domain?

https://bugzilla.mozilla.org/show_bug.cgi?id=614930

But then there's RFC 5335 which seems to go further, although, frankly speaking, I'd love to see examples in RFCs every now and then, and it sounds like it's not exactly supported by too many mailers along the way.

http://tools.ietf.org/html/rfc5335

Either way, if the Mozilla example is something to live up to, I hope I'll be allowed to have WS between a non-UTF-8 '<', the UTF-8 local part and the '@', because email.Headers will always create that, right?

Is there a place I can register such a fancy email address (AND understand the website and webmailer's UI) for testing purposes?

Hats off to you who is dealing with these ugly compromises, keeping an outdated underlying standard on life support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 17:39:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jul 2011 15:39:47 +0000
Subject: [issue11439] subversion keyword breakage
In-Reply-To: <1299597022.39.0.100246713924.issue11439@psf.upfronthosting.co.za>
Message-ID: <E1QmSgb-0003Xx-A6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f15442543e24 by Senthil Kumaran in branch '2.7':
Fix closes Issue11439 - Handle the SVN Keywords in 2.7 by replacing them with a high number so that code relying on them does not break.
http://hg.python.org/cpython/rev/f15442543e24

New changeset 3e26c9033306 by Senthil Kumaran in branch '3.2':
Fix closes Issue11439 Remove the SVN keywords from the code as it is no longer applicable in hg. Patch Contributed by Neil Muller.
http://hg.python.org/cpython/rev/3e26c9033306

New changeset 6b9f0a6efaeb by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes Issue11439 Remove the SVN keywords from the code as it is no longer applicable in hg. Patch Contributed by Neil Muller.
http://hg.python.org/cpython/rev/6b9f0a6efaeb

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11439>
_______________________________________

From report at bugs.python.org  Thu Jul 28 17:43:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 28 Jul 2011 15:43:12 +0000
Subject: [issue11439] subversion keyword breakage
In-Reply-To: <1309863404.22.0.43484594151.issue11439@psf.upfronthosting.co.za>
Message-ID: <20110728154304.GA2135@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the patch, Neil.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11439>
_______________________________________

From report at bugs.python.org  Thu Jul 28 17:53:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 15:53:20 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311868400.8.0.836129793759.issue12649@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Interesting thread.  I have my eye on supporting 5335 in the revised email package, but it is secondary goal to getting an improved API for the already-accepted RFCs.

You will note that the encoded word local part is *not* standard.  I think the email package may decode them anyway, but just like TB it provides no mechanism for creating them in the first place since it is not RFC compliant.  You could open a feature request for adding support for doing so (as an *optional* feature :), which I would then try to get in to 3.3.  (It puzzles me why it *isn't* allowed by the RFC, by the way).

To do it yourself now, you will probably have to create a temporary Header, pass it just the local part, call its encode or __str__ to get the encoded word (which won't have any spaces since it will be the only token), and then format that in to your rebuilt address string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 18:02:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 28 Jul 2011 16:02:01 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1311868921.76.0.184956056621.issue12650@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

There's indeed a leak in your code, because you don't close the stdout and stderr file descriptors.

Try with:

    subp.terminate()
    subp.stdout.close()
    subp.stderr.close()
    return True

And you'll be just fine.

The reason why this works with a short delay is subtle however, and there's actually a bug:
- when a subprocess.Popen is created, its stdout and stderr are wrapped with os.fdopen()
- file objects returned by fdopen() are automatically closed when the object is deallocated (i.e. when the file object goes out of scope in cPython)
- so in theory, when your subprocess.Popen goes out of scope, the corresponding FDs should be closed, and you shoudn't have a leak (note that this assumes cPython, and will maybe not work with other implementations - you shouldn't rely on this)
- the problem is that when subprocess.Popen's __del__ method is called before the process has exited (i.e. if you return from leaktest() before the process has exited), the Popen object is added to a list (subprocess._active), so that it can be waited (to avoid zombies)
- Popen objects from this list are collected (i.e. the process is waited for, and if terminated it's removed from the list) synchronously when a new Popen() object is created (_cleanup funtion)

The problem is that there's a bug in the collection code:

def _cleanup():
    for inst in _active[:]:
       res = inst._internal_poll(_deadstate=sys.maxint)
       if res is not None and res >= 0:
           try:
               _active.remove(inst)
           except ValueError:
               # This can happen if two threads create a new Popen instance.
               # It's harmless that it was already removed, so ignore.
               pass

       res = inst._internal_poll(_deadstate=sys.maxint)
       if res is not None and res >= 0:

If the process exit code is negative (in your case, -SIGTERM) then the Popen object is not removed from the list.
Two consequences:
- the object is not deallocated, the corresponding FDs neither, and you hit RLIMIT_NOFILE
- even if stdout and stderr are closed manually, the object itself is not deallocated, so you have an ever-growing _active list, and a memory leak (and walking the list takes longer and longer)

Changing
       if res is not None and res >= 0:
to
       if res is not None:

fixes this.
I'll look at this in more detail and provide a patch.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Jul 28 18:05:32 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 28 Jul 2011 16:05:32 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311869132.13.0.0560702571697.issue12647@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/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 18:08:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Jul 2011 16:08:56 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1311869336.1.0.809243544244.issue12650@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/issue12650>
_______________________________________

From report at bugs.python.org  Thu Jul 28 18:22:37 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 28 Jul 2011 16:22:37 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1311870157.02.0.109428743371.issue12650@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Jul 28 18:55:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Jul 2011 16:55:30 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <E1QmTrr-00024M-Jk@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ccce01988603 by Raymond Hettinger in branch 'default':
Issue 12647: Add __bool__() method to the None object.
http://hg.python.org/cpython/rev/ccce01988603

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 18:56:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Jul 2011 16:56:42 +0000
Subject: [issue12647] Add __bool__ to None
In-Reply-To: <1311794776.71.0.254853675833.issue12647@psf.upfronthosting.co.za>
Message-ID: <1311872202.96.0.117003952771.issue12647@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12647>
_______________________________________

From report at bugs.python.org  Thu Jul 28 19:55:48 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 28 Jul 2011 17:55:48 +0000
Subject: [issue12595] python.h redundant redeclarations
In-Reply-To: <1311174991.79.0.412639363077.issue12595@psf.upfronthosting.co.za>
Message-ID: <1311875748.73.0.445049940246.issue12595@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Barry Warsaw wrote:
> I don't feel comfortable changing what is defined in
> a header file in a point release, so I am not going
> to backport the fix.

Closing as wont fix.

----------
keywords: +needs review
resolution:  -> wont fix
stage: needs patch -> patch review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12595>
_______________________________________

From report at bugs.python.org  Thu Jul 28 20:18:20 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 28 Jul 2011 18:18:20 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1311877100.45.0.164847068002.issue12611@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I cannot reproduce the crash on neither 2.7 nor 3.2. Can you provide more details; attach the exact python source file that crashes 2to3 and give the complete crashing 2to3 command that you're running.

----------
nosy: +petri.lehtinen
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12611>
_______________________________________

From report at bugs.python.org  Thu Jul 28 20:42:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 28 Jul 2011 18:42:37 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1311878557.89.0.0595898993711.issue11699@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch for 2.7.

----------
keywords: +easy, needs review, patch
nosy: +petri.lehtinen
versions:  -Python 3.1
Added file: http://bugs.python.org/file22785/issue11699.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Thu Jul 28 20:42:56 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 28 Jul 2011 18:42:56 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1311878576.35.0.384292255294.issue11699@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Thu Jul 28 21:01:20 2011
From: report at bugs.python.org (dandre)
Date: Thu, 28 Jul 2011 19:01:20 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311879680.75.0.480715318281.issue12649@psf.upfronthosting.co.za>


dandre <andre.d at gmx.net> added the comment:

I made a test and, interestingly, I /can/ send an email to myself setting up the header like this:

h.append(b'My Name',         charset='utf-8')
h.append(b' < ',             charset='us-ascii')
h.append(b'my',              charset='utf-8')
h.append(b'@email.address>', charset='us-ascii')

The message in my Inbox will then have a To: header along the lines of
"=?utf-8?q?My Name?= <=?utf-8?q?my?=@email.address>
so the mailers are sure nice to me.

The startling part of it all seems to be that such email addresses are already out there and seem to be supported by enough mailers, albeit not by enough client-side systems.

With this non-standard approach and RFC 5335, I feel tempted to hope for a helper method which finds "the" ("an") canonical form of an email address...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 21:11:44 2011
From: report at bugs.python.org (dandre)
Date: Thu, 28 Jul 2011 19:11:44 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311880304.02.0.766033696524.issue12649@psf.upfronthosting.co.za>


dandre <andre.d at gmx.net> added the comment:

Erm, sorry.
The header, of course, does not have much to do with the address the email is to be delivered to.
With my provider's setup, the mailer will reply that =?utf-8?q?my?= is not a known user.
Which could change, of course...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 21:18:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jul 2011 19:18:15 +0000
Subject: [issue12649] email.Header ignores maxlinelen when wrapping encoded
	words
In-Reply-To: <1311858906.9.0.41182214935.issue12649@psf.upfronthosting.co.za>
Message-ID: <1311880695.18.0.204889004831.issue12649@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, exactly.  It is a valid ascii token so MTA's pass it through.  It's the receiving system that needs to be willing to decode it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12649>
_______________________________________

From report at bugs.python.org  Thu Jul 28 22:11:58 2011
From: report at bugs.python.org (Jesus Rivero)
Date: Thu, 28 Jul 2011 20:11:58 +0000
Subject: [issue12619] Automatically regenerate platform-specific modules
In-Reply-To: <1311414212.95.0.467545301683.issue12619@psf.upfronthosting.co.za>
Message-ID: <1311883918.93.0.795338533175.issue12619@psf.upfronthosting.co.za>


Changes by Jesus Rivero <neurogeek at gentoo.org>:


----------
nosy: +Neurogeek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12619>
_______________________________________

From report at bugs.python.org  Thu Jul 28 22:32:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 28 Jul 2011 20:32:55 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1311885175.41.0.400623503714.issue11657@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch for v2.7. It changes the assignments to memcpy() calls.

----------
keywords: +easy, needs review, patch
nosy: +petri.lehtinen
stage:  -> patch review
versions:  -Python 3.1
Added file: http://bugs.python.org/file22786/issue11657.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Thu Jul 28 22:39:16 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 28 Jul 2011 20:39:16 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1311885556.1.0.821320258993.issue11657@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

Thanks for the patch Petri.  Are you interested in writing a unit test for this as well?

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Thu Jul 28 23:30:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 28 Jul 2011 21:30:25 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311870157.07.0.097531971848.issue12650@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3Dht49vWiqdmbLzus3wzGLmxA=KQgW-uE6Pp9z+gpE9A@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Alright.
I tested this on default, and couldn't reproduce the FD leak.
It turned out to be due to another bug, affecting only the code path
which calls pure C _posixsubprocess (which is the only implementation
left in 3.3, but 3.2 still has the old pure-Python version).
The code just forgets to set Popen._child_created to true after
fork(), so when Popen.__del__() gets called before the process has
exited, the object is not added to the _active list, and gets
deallocated immediately. While this accidentaly "fixes" the FD leak,
this has another - worse - side effet: the process remains a zombie.

I'm thus attaching three patches, with tests:
- one for 2.7, which fixes the original problem (i.e. remove the
process from _active once exited, even if it got killed by a signal)
- one for default, which also sets _child_created to True after fork()
- another one for 3.2, which does the same thing as the one for
default (but the code is a little different because 3.2 has both
pure-Python and C implementation)

Reviews welcome!

----------
keywords: +patch
Added file: http://bugs.python.org/file22787/issue_12650_default.diff
Added file: http://bugs.python.org/file22788/issue_12650_27.diff
Added file: http://bugs.python.org/file22789/issue_12650_32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________
-------------- next part --------------
diff -r ccce01988603 Lib/subprocess.py
--- a/Lib/subprocess.py	Thu Jul 28 09:55:13 2011 -0700
+++ b/Lib/subprocess.py	Thu Jul 28 22:51:39 2011 +0200
@@ -424,12 +424,16 @@
 except:
     MAXFD = 256
 
+# This lists holds Popen instances for which the underlying process had not
+# exited at the time its __del__ method got called: those processes are wait()ed
+# for synchronously from _cleanup() when a new Popen object is created, to avoid
+# zombie processes.
 _active = []
 
 def _cleanup():
     for inst in _active[:]:
         res = inst._internal_poll(_deadstate=sys.maxsize)
-        if res is not None and res >= 0:
+        if res is not None:
             try:
                 _active.remove(inst)
             except ValueError:
@@ -1272,6 +1276,7 @@
                             errread, errwrite,
                             errpipe_read, errpipe_write,
                             restore_signals, start_new_session, preexec_fn)
+                    self._child_created = True
                 finally:
                     # be sure the FD is closed no matter what
                     os.close(errpipe_write)
diff -r ccce01988603 Lib/test/test_subprocess.py
--- a/Lib/test/test_subprocess.py	Thu Jul 28 09:55:13 2011 -0700
+++ b/Lib/test/test_subprocess.py	Thu Jul 28 22:51:39 2011 +0200
@@ -1622,6 +1622,63 @@
             if dir is not None:
                 os.rmdir(dir)
 
+    def test_zombie_fast_process_del(self):
+        # Issue #12650: on Unix, if Popen.__del__() was called before the
+        # process exited, it wouldn't be added to subprocess._active, and would
+        # remain a zombie.
+        # spawn a Popen, and delete its reference before it exits
+        p = subprocess.Popen([sys.executable, "-c",
+                              'import sys, time;'
+                              'time.sleep(0.2)'],
+                             stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        ident = id(p)
+        pid = p.pid
+        del p
+        # check that p is in the active processes list
+        self.assertIn(ident, [id(o) for o in subprocess._active])
+
+        # sleep a little to let the process exit, and create a new Popen: this
+        # should trigger the wait() of p
+        time.sleep(1)
+        with self.assertRaises(EnvironmentError) as c:
+            with subprocess.Popen(['nonexisting_i_hope'],
+                                  stdout=subprocess.PIPE,
+                                  stderr=subprocess.PIPE) as proc:
+                pass
+        # p should have been wait()ed on, and removed from the _active list
+        self.assertRaises(OSError, os.waitpid, pid, 0)
+        self.assertNotIn(ident, [id(o) for o in subprocess._active])
+
+    def test_leak_fast_process_del_killed(self):
+        # Issue #12650: on Unix, if Popen.__del__() was called before the
+        # process exited, and the process got killed by a signal, it would never
+        # be removed from subprocess._active, which triggered a FD and memory
+        # leak.
+        # spawn a Popen, delete its reference and kill it
+        p = subprocess.Popen([sys.executable, "-c",
+                              'import time;'
+                              'time.sleep(3)'],
+                             stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        ident = id(p)
+        pid = p.pid
+        del p
+        os.kill(pid, signal.SIGKILL)
+        # check that p is in the active processes list
+        self.assertIn(ident, [id(o) for o in subprocess._active])
+
+        # let some time for the process to exit, and create a new Popen: this
+        # should trigger the wait() of p
+        time.sleep(0.2)
+        with self.assertRaises(EnvironmentError) as c:
+            with subprocess.Popen(['nonexisting_i_hope'],
+                                  stdout=subprocess.PIPE,
+                                  stderr=subprocess.PIPE) as proc:
+                pass
+        # p should have been wait()ed on, and removed from the _active list
+        self.assertRaises(OSError, os.waitpid, pid, 0)
+        self.assertNotIn(ident, [id(o) for o in subprocess._active])
 
 @unittest.skipUnless(getattr(subprocess, '_has_poll', False),
                      "poll system call not supported")
-------------- next part --------------
diff -r f15442543e24 Lib/subprocess.py
--- a/Lib/subprocess.py	Thu Jul 28 22:30:27 2011 +0800
+++ b/Lib/subprocess.py	Thu Jul 28 23:15:12 2011 +0200
@@ -460,7 +460,7 @@
 def _cleanup():
     for inst in _active[:]:
         res = inst._internal_poll(_deadstate=sys.maxint)
-        if res is not None and res >= 0:
+        if res is not None:
             try:
                 _active.remove(inst)
             except ValueError:
diff -r f15442543e24 Lib/test/test_subprocess.py
--- a/Lib/test/test_subprocess.py	Thu Jul 28 22:30:27 2011 +0800
+++ b/Lib/test/test_subprocess.py	Thu Jul 28 23:15:12 2011 +0200
@@ -1080,6 +1080,63 @@
                          subprocess._eintr_retry_call(fake_os_func, 666))
         self.assertEqual([(256, 999), (666,), (666,)], record_calls)
 
+    def test_zombie_fast_process_del(self):
+        # Issue #12650: on Unix, if Popen.__del__() was called before the
+        # process exited, it wouldn't be added to subprocess._active, and would
+        # remain a zombie.
+        # spawn a Popen, and delete its reference before it exits
+        p = subprocess.Popen([sys.executable, "-c",
+                              'import sys, time;'
+                              'time.sleep(0.2)'],
+                             stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        ident = id(p)
+        pid = p.pid
+        del p
+        # check that p is in the active processes list
+        self.assertIn(ident, [id(o) for o in subprocess._active])
+
+        # sleep a little to let the process exit, and create a new Popen: this
+        # should trigger the wait() of p
+        time.sleep(1)
+        with self.assertRaises(EnvironmentError) as c:
+            with subprocess.Popen(['nonexisting_i_hope'],
+                                  stdout=subprocess.PIPE,
+                                  stderr=subprocess.PIPE) as proc:
+                pass
+        # p should have been wait()ed on, and removed from the _active list
+        self.assertRaises(OSError, os.waitpid, pid, 0)
+        self.assertNotIn(ident, [id(o) for o in subprocess._active])
+
+    def test_leak_fast_process_del_killed(self):
+        # Issue #12650: on Unix, if Popen.__del__() was called before the
+        # process exited, and the process got killed by a signal, it would never
+        # be removed from subprocess._active, which triggered a FD and memory
+        # leak.
+        # spawn a Popen, delete its reference and kill it
+        p = subprocess.Popen([sys.executable, "-c",
+                              'import time;'
+                              'time.sleep(3)'],
+                             stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        ident = id(p)
+        pid = p.pid
+        del p
+        os.kill(pid, signal.SIGKILL)
+        # check that p is in the active processes list
+        self.assertIn(ident, [id(o) for o in subprocess._active])
+
+        # let some time for the process to exit, and create a new Popen: this
+        # should trigger the wait() of p
+        time.sleep(0.2)
+        with self.assertRaises(EnvironmentError) as c:
+            with subprocess.Popen(['nonexisting_i_hope'],
+                                  stdout=subprocess.PIPE,
+                                  stderr=subprocess.PIPE) as proc:
+                pass
+        # p should have been wait()ed on, and removed from the _active list
+        self.assertRaises(OSError, os.waitpid, pid, 0)
+        self.assertNotIn(ident, [id(o) for o in subprocess._active])
 
 @unittest.skipUnless(mswindows, "mswindows only")
 class CommandsWithSpaces (BaseTestCase):
-------------- next part --------------
diff -r 3e26c9033306 Lib/subprocess.py
--- a/Lib/subprocess.py	Thu Jul 28 22:32:49 2011 +0800
+++ b/Lib/subprocess.py	Thu Jul 28 23:17:57 2011 +0200
@@ -429,12 +429,16 @@
 except:
     MAXFD = 256
 
+# This lists holds Popen instances for which the underlying process had not
+# exited at the time its __del__ method got called: those processes are wait()ed
+# for synchronously from _cleanup() when a new Popen object is created, to avoid
+# zombie processes.
 _active = []
 
 def _cleanup():
     for inst in _active[:]:
         res = inst._internal_poll(_deadstate=sys.maxsize)
-        if res is not None and res >= 0:
+        if res is not None:
             try:
                 _active.remove(inst)
             except ValueError:
@@ -1191,6 +1195,7 @@
                                 errread, errwrite,
                                 errpipe_read, errpipe_write,
                                 restore_signals, start_new_session, preexec_fn)
+                        self._child_created = True
                     else:
                         # Pure Python implementation: It is not thread safe.
                         # This implementation may deadlock in the child if your
diff -r 3e26c9033306 Lib/test/test_subprocess.py
--- a/Lib/test/test_subprocess.py	Thu Jul 28 22:32:49 2011 +0800
+++ b/Lib/test/test_subprocess.py	Thu Jul 28 23:17:57 2011 +0200
@@ -1525,6 +1525,63 @@
             if dir is not None:
                 os.rmdir(dir)
 
+    def test_zombie_fast_process_del(self):
+        # Issue #12650: on Unix, if Popen.__del__() was called before the
+        # process exited, it wouldn't be added to subprocess._active, and would
+        # remain a zombie.
+        # spawn a Popen, and delete its reference before it exits
+        p = subprocess.Popen([sys.executable, "-c",
+                              'import sys, time;'
+                              'time.sleep(0.2)'],
+                             stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        ident = id(p)
+        pid = p.pid
+        del p
+        # check that p is in the active processes list
+        self.assertIn(ident, [id(o) for o in subprocess._active])
+
+        # sleep a little to let the process exit, and create a new Popen: this
+        # should trigger the wait() of p
+        time.sleep(1)
+        with self.assertRaises(EnvironmentError) as c:
+            with subprocess.Popen(['nonexisting_i_hope'],
+                                  stdout=subprocess.PIPE,
+                                  stderr=subprocess.PIPE) as proc:
+                pass
+        # p should have been wait()ed on, and removed from the _active list
+        self.assertRaises(OSError, os.waitpid, pid, 0)
+        self.assertNotIn(ident, [id(o) for o in subprocess._active])
+
+    def test_leak_fast_process_del_killed(self):
+        # Issue #12650: on Unix, if Popen.__del__() was called before the
+        # process exited, and the process got killed by a signal, it would never
+        # be removed from subprocess._active, which triggered a FD and memory
+        # leak.
+        # spawn a Popen, delete its reference and kill it
+        p = subprocess.Popen([sys.executable, "-c",
+                              'import time;'
+                              'time.sleep(3)'],
+                             stdout=subprocess.PIPE,
+                             stderr=subprocess.PIPE)
+        ident = id(p)
+        pid = p.pid
+        del p
+        os.kill(pid, signal.SIGKILL)
+        # check that p is in the active processes list
+        self.assertIn(ident, [id(o) for o in subprocess._active])
+
+        # let some time for the process to exit, and create a new Popen: this
+        # should trigger the wait() of p
+        time.sleep(0.2)
+        with self.assertRaises(EnvironmentError) as c:
+            with subprocess.Popen(['nonexisting_i_hope'],
+                                  stdout=subprocess.PIPE,
+                                  stderr=subprocess.PIPE) as proc:
+                pass
+        # p should have been wait()ed on, and removed from the _active list
+        self.assertRaises(OSError, os.waitpid, pid, 0)
+        self.assertNotIn(ident, [id(o) for o in subprocess._active])
 
 @unittest.skipUnless(getattr(subprocess, '_has_poll', False),
                      "poll system call not supported")

From report at bugs.python.org  Fri Jul 29 00:09:13 2011
From: report at bugs.python.org (Pedro Larroy)
Date: Thu, 28 Jul 2011 22:09:13 +0000
Subject: [issue12651] -O2 or -O3? this brings excitement to computing!
In-Reply-To: <1311890952.9.0.743029237922.issue12651@psf.upfronthosting.co.za>
Message-ID: <1311890952.9.0.743029237922.issue12651@psf.upfronthosting.co.za>


New submission from Pedro Larroy <pedro.larroy at gmail.com>:

When I build it compiles with both -O2 and -O3...

this is debian testing on amd64.

gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/getcompiler.o Python/getcompiler.c

----------
components: Build
messages: 141318
nosy: Pedro.Larroy
priority: normal
severity: normal
status: open
title: -O2 or -O3? this brings excitement to computing!
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12651>
_______________________________________

From report at bugs.python.org  Fri Jul 29 00:14:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Jul 2011 22:14:02 +0000
Subject: [issue12651] -O2 or -O3? this brings excitement to computing!
In-Reply-To: <1311890952.9.0.743029237922.issue12651@psf.upfronthosting.co.za>
Message-ID: <1311891242.9.0.785405555257.issue12651@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

AFAICT the last one (-O3) is used by the compiler and that's the desired effect (we want to compile with the highest optimization level).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12651>
_______________________________________

From report at bugs.python.org  Fri Jul 29 00:18:18 2011
From: report at bugs.python.org (Aaron Meurer)
Date: Thu, 28 Jul 2011 22:18:18 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1311891498.37.0.126168056694.issue12611@psf.upfronthosting.co.za>


Aaron Meurer <asmeurer at gmail.com> added the comment:

Vladimir will need to confirm how to reproduce this exactly, but here is corresponding SymPy issue: http://code.google.com/p/sympy/issues/detail?id=2605.

The problem is with the sympy/ntheory/factor_.py file at https://github.com/sympy/sympy/blob/sympy-0.7.1.rc1/sympy/ntheory/factor_.py#L453 (linking to the file from our release candidate, as a workaround is likely to be pushed to master soon).

Vladimir, can you confirm that this particular version of the file reproduces the problem?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12611>
_______________________________________

From report at bugs.python.org  Fri Jul 29 00:22:06 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 Jul 2011 22:22:06 +0000
Subject: [issue12651] -O2 or -O3? this brings excitement to computing!
In-Reply-To: <1311890952.9.0.743029237922.issue12651@psf.upfronthosting.co.za>
Message-ID: <1311891726.9.0.19619694551.issue12651@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in default. It's harmless in other versions.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12651>
_______________________________________

From report at bugs.python.org  Fri Jul 29 01:10:01 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 28 Jul 2011 23:10:01 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1311894601.61.0.531723042408.issue1813@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Fedora bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=726536

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Fri Jul 29 02:02:44 2011
From: report at bugs.python.org (Catherine Devlin)
Date: Fri, 29 Jul 2011 00:02:44 +0000
Subject: [issue11472] upload command fails to read auth information from
	.pypirc
In-Reply-To: <1299882429.66.0.49580074551.issue11472@psf.upfronthosting.co.za>
Message-ID: <1311897764.81.0.780164049456.issue11472@psf.upfronthosting.co.za>


Catherine Devlin <fredv8vibwc at liquidid.net> added the comment:

This blog post

http://justcramer.com/2009/04/02/problems-uploading-packages-with-setuptools-on-os-x/

describes working around the same problem by replacing [pypi] in .pypirc with [server-login].  Is that the problem, a change in .pypirc formats?

----------
nosy: +catherine, catherinedevlin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11472>
_______________________________________

From report at bugs.python.org  Fri Jul 29 02:32:08 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 29 Jul 2011 00:32:08 +0000
Subject: [issue11472] upload command fails to read auth information from
	.pypirc
In-Reply-To: <1299882429.66.0.49580074551.issue11472@psf.upfronthosting.co.za>
Message-ID: <1311899528.76.0.799928935097.issue11472@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I don't believe that's the issue. The [server-login] is for Python 2.5 and earlier. Also note that I already had [server-login] in the .pypirc when the error occurred, so I don't think that's a factor either.

This same .pypirc works just fine on Python 2.5, 2.6, and 2.7, so I believe the regression is somewhere in the Python 3 line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11472>
_______________________________________

From report at bugs.python.org  Fri Jul 29 05:55:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 03:55:44 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311911744.44.0.377829275418.issue10639@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

It appears this breaks "make patchcheck" in trunk:

./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 5 files
Fixing whitespace ... Traceback (most recent call last):
  File "./Tools/scripts/patchcheck.py", line 147, in <module>
    main()
  File "./Tools/scripts/patchcheck.py", line 129, in main
    normalize_whitespace(python_files)
  File "./Tools/scripts/patchcheck.py", line 22, in call_fxn
    result = fxn(*args, **kwargs)
  File "./Tools/scripts/patchcheck.py", line 66, in normalize_whitespace
    fixed = [path for path in file_paths if path.endswith('.py') and
  File "./Tools/scripts/patchcheck.py", line 67, in <listcomp>
    reindent.check(path)]
  File "/home/eliben/python-src/33/Tools/scripts/reindent.py", line 129, in check
    newline = spec_newline if spec_newline else r.newlines
NameError: global name 'spec_newline' is not defined
make: *** [patchcheck] Error 1

----------
nosy: +eli.bendersky
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 06:07:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 04:07:06 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <E1QmeLn-0006io-C2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 536fccc75f5a by Eli Bendersky in branch 'default':
Issue #12380: PyArg_ParseTuple now accepts a bytearray for the 'c' format.
http://hg.python.org/cpython/rev/536fccc75f5a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Fri Jul 29 06:08:47 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 04:08:47 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311912527.22.0.187632166038.issue12380@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Petri, thanks for the patch. I've updated Misc/NEWS and committed it.

Unless there are objections or problems, I will close this issue in a day or two.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Fri Jul 29 06:31:42 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 04:31:42 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311913902.18.0.0901675372936.issue10639@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
priority: normal -> high
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 06:34:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 04:34:36 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311914076.9.0.822724462793.issue10639@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

This is a good example of why passing parameters into functions by means of globals sucks. In reindent.py, main() sets the spec_newline global which check() uses, but this was forgotten in patchcheck.py which also uses reindent.check()

IMHO reindent.py should be rewritten to ditch all globals

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 07:43:06 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 29 Jul 2011 05:43:06 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1311918186.62.0.787588743173.issue12650@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

The patches look good and seem to fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Fri Jul 29 08:04:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 06:04:14 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311919454.19.0.726531087484.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry,

""" When I tried the same fix in idlelib/PyShell.py, adding 'import subprocess' and changing
        self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args)
to
        self.rpcpid = subprocess.Popen(args).pid
(args begins with sys.executable) IDLE failed to start. The only evidence that it had been invoked was a brief (1/4 second?) appearance of 1 pythonw process in task manager. On a subsequent tries, without touching the file, I do not see even that. Is there any obvious mistake in the above? """

No, when I do the same, things seem to go fine. No zombie is left running after IDLE is closed, and even "Restart shell" works without leaving a zombie.

Maybe you had other modifications in your idlelib sources? 

Anyway, this wouldn't be a complete fix, because in:

    def unix_terminate(self):
        "UNIX: make sure subprocess is terminated and collect status"
        if hasattr(os, 'kill'):
            try:
                os.kill(self.rpcpid, SIGTERM)
            except OSError:
                # process already terminated:
                return
            else:
                try:
                    os.waitpid(self.rpcpid, 0)
                except OSError:
                    return

os.waitpid on Windows also expects a process handle, not pid. 

I think the complete solution, in addition to replacing os.spawnv by subprocess.Popen, would be to use Popen.kill and then Popen.wait instead of os.kill and then os.wait in the code above. This would require keeping the Popen object somewhere in self.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Fri Jul 29 08:35:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 06:35:49 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <E1Qmgfj-0000ny-Hs@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9846f6463f23 by Eli Bendersky in branch '3.2':
Issue #12644: document the '%a' conversion in the old string formatting operations. Patch prepared together with Ezio Melotti
http://hg.python.org/cpython/rev/9846f6463f23

New changeset 80a3bf889cf6 by Eli Bendersky in branch 'default':
Merge from 3.2: Issue #12644: document the '%a' conversion in the old string formatting operations. Patch prepared together with Ezio Melotti
http://hg.python.org/cpython/rev/80a3bf889cf6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Fri Jul 29 08:43:34 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 06:43:34 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311921814.38.0.761163915508.issue12644@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Ezio, I've taken the liberty to adapt your patch with the suggested fixes and commit it to both 3.2 and 3.3

If everything is OK, this issue can be close (I'll do it in a few days if no one else does :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Fri Jul 29 08:47:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jul 2011 06:47:47 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311922067.28.0.122426390693.issue12644@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The commit looks fine, the issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Fri Jul 29 08:49:34 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 06:49:34 +0000
Subject: [issue12644] document the "%a" conversion in the old string
	formatting operations
In-Reply-To: <1311776954.08.0.677656936944.issue12644@psf.upfronthosting.co.za>
Message-ID: <1311922174.42.0.0181649018331.issue12644@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12644>
_______________________________________

From report at bugs.python.org  Fri Jul 29 08:56:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 06:56:48 +0000
Subject: [issue12514] timeit disables garbage collection if timed code raises
	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <E1Qmh03-0002IC-DZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 56e7b42089c8 by Raymond Hettinger in branch '2.7':
Issue 12514: Use try/finally to assure that timeit restores GC when done.
http://hg.python.org/cpython/rev/56e7b42089c8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12514>
_______________________________________

From report at bugs.python.org  Fri Jul 29 09:08:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 07:08:29 +0000
Subject: [issue12514] timeit disables garbage collection if timed code raises
	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <E1QmhBL-0003EW-U3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1cdb281a78ce by Raymond Hettinger in branch '3.2':
Issue 12514: Use try/finally to assure that timeit restores GC when done.
http://hg.python.org/cpython/rev/1cdb281a78ce

New changeset 7df53f5788a4 by Raymond Hettinger in branch 'default':
Issue 12514: Use try/finally to assure that timeit restores GC when done.
http://hg.python.org/cpython/rev/7df53f5788a4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12514>
_______________________________________

From report at bugs.python.org  Fri Jul 29 09:09:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Jul 2011 07:09:16 +0000
Subject: [issue12514] timeit disables garbage collection if timed code raises
	an exception
In-Reply-To: <1310050733.66.0.963908910352.issue12514@psf.upfronthosting.co.za>
Message-ID: <1311923356.44.0.458495324389.issue12514@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the bug report and patch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12514>
_______________________________________

From report at bugs.python.org  Fri Jul 29 09:45:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 07:45:25 +0000
Subject: [issue12652] Move documentation of test.support into the devguide
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

First step in transition:

Attaching a patch to devguide's runtests.rst to incorporate existing test.support documentation from 3.3 head, with some small markup changes suitable for the devguide.

----------
components: Devguide
files: devguide_test_support.1.patch
keywords: patch
messages: 141337
nosy: brett.cannon, docs at python, eli.bendersky, ncoghlan
priority: low
severity: normal
stage: patch review
status: open
title: Move documentation of test.support into the devguide
type: behavior
Added file: http://bugs.python.org/file22790/devguide_test_support.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12652>
_______________________________________

From report at bugs.python.org  Fri Jul 29 09:50:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Jul 2011 07:50:05 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311925805.29.0.519441094552.issue12540@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/issue12540>
_______________________________________

From report at bugs.python.org  Fri Jul 29 09:52:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Jul 2011 07:52:37 +0000
Subject: [issue12652] Move documentation of test.support into the devguide
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1311925957.73.0.808326256409.issue12652@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/issue12652>
_______________________________________

From report at bugs.python.org  Fri Jul 29 09:56:04 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 07:56:04 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1311926164.45.0.211690428589.issue11699@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/issue11699>
_______________________________________

From report at bugs.python.org  Fri Jul 29 11:08:21 2011
From: report at bugs.python.org (Marian Ganisin)
Date: Fri, 29 Jul 2011 09:08:21 +0000
Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an
	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1311930501.98.0.761819522671.issue10131@psf.upfronthosting.co.za>


Marian Ganisin <marian.ganisin at gmail.com> added the comment:

xml.dom.minicompat.NodeList provides __reduce__/__reduce_ex__ methods, they return "state" as well as "list iterator". However one of those seems to be absolutely enough for reconstruction of instance (__reduce__/__reduce_ex__ are inherited, methods __setstate/__getstate__ aka state provider/consumer are defined in NodeList).

deepcopy (actually its helper function _reconstruct) uses both, state and list iterator for copying, first it calls __setstate__(state) on new copy, then it goes through iterator and calls append(item) (as it is probably common for lists). This is it! (state and list iterator contain same information, list of items)

Prior to some minor 2.7 update deepcopy used list iterator and state in opposite order, first it run append through iterator, then __setstate__ (this overwrote new content at all, no unwanted copies appeared). So the issue is there all the time, just with no impact in the past.

Issue also occurs with simple copy.copy() on NodeList:

>>> import copy
>>> from xml.dom import minidom
>>> doc = minidom.parseString('<root/>')
>>> print copy.copy(doc.childNodes)
[<DOM Element: root at 0xb73fbbcc>, <DOM Element: root at 0xb73fbbcc>]

I am strongly convinced NodeList doesn't require __setstate__/__getstate__ methods (even more I believe they are not desired in subclass of list). Therefore I am proposing patch with removal of these methods.

If I am wrong in my final decision, somebody smarter has to find a solution. This is the reason why I described issue in deep. :)

----------
keywords: +patch
nosy: +Marian.Ganisin
Added file: http://bugs.python.org/file22791/mganisin-Issue10131-Python-2.7.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10131>
_______________________________________

From report at bugs.python.org  Fri Jul 29 11:28:06 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Jul 2011 09:28:06 +0000
Subject: [issue12652] Move documentation of test.support into the devguide
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1311931686.42.0.15025803216.issue12652@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

As I just mentioned on python-dev (via Gmane), I'm uncomfortable with moving the documentation for test.support into the devguide.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12652>
_______________________________________

From report at bugs.python.org  Fri Jul 29 12:36:23 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 29 Jul 2011 10:36:23 +0000
Subject: [issue12653] Provide accelerators for all buttons in Windows
	installers
In-Reply-To: <1311935783.8.0.769443256699.issue12653@psf.upfronthosting.co.za>
Message-ID: <1311935783.8.0.769443256699.issue12653@psf.upfronthosting.co.za>


New submission from Ram Rachum <ram at rachum.com>:

I was installing Python 3.2.1 on my laptop today, and was unable to efficiently use the keyboard in order to navigate the installation dialogs. Every button should have an accelerator, e.g. "Next" should be "&Next" so Alt-N will press it. (I don't know whether you use the ampersand notation or something else.)

----------
messages: 141340
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Provide accelerators for all buttons in Windows installers
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12653>
_______________________________________

From report at bugs.python.org  Fri Jul 29 13:00:15 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 11:00:15 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1311937215.0.0.618089359248.issue11699@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Petri,

I think the "to" after "belongs" is redundant.

Also, the issue lists 3.2 and 3.3 - is the fix relevant there too? If yes, can you prepare a patch for 3.2? (I will merge it to 3.3 too)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Fri Jul 29 13:47:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 11:47:08 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <E1QmlX0-0007of-Gf@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8328fe952303 by Eli Bendersky in branch '2.7':
Issue #12531: add index entries to documentation of * and ** in function calls
http://hg.python.org/cpython/rev/8328fe952303

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Fri Jul 29 13:48:15 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 11:48:15 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311940095.03.0.53916174215.issue12531@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I've committed a fix into 2.7, taking Terry's advice ("in function calls" subsection instead of "statement") and Eric's sequence/iterable correction into account.

If this looks OK, I will commit a similar fix to the 3.x branches as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:14:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 12:14:27 +0000
Subject: [issue12652] Move documentation of test.support into the devguide
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1311941667.63.0.736470872967.issue12652@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/issue12652>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:27:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Jul 2011 12:27:27 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1311942447.0.0.677450375078.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I was working with the freshly reinstalled 3.2 which is not the same as a pristine 3.2 install because it still had the problem that 3.2.1 has and the 3.2.1 sys.version. 3.2.1 uninstall in not complete (a different issue). So I should reinstall 3.2.1 again and try again.

I agree about fully switching t. subprocess. If self.rpcpid is not used anywhere other than unix_terminate (which I think should be renamed)), then self.subproc could replace self.rpcpid.

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 12:35:07 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311942907.51.0.254785554428.issue670664@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I also think this is a bug that should be fixed. Not being able to parse real-world HTML is a nuisance.

I agree with Ezio's review comments about the custom regex.

----------
assignee: fdrake -> 
nosy: +pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:17 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-Rx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4d351135f128 by ?ric Araujo in branch '3.2':
Make VCSes ignore the compiled shared library file (#12255)
http://hg.python.org/cpython/rev/4d351135f128

New changeset bdad5bc9a2ed by ?ric Araujo in branch '3.2':
Stop ignoring Mercurial merge conflits files (#12255).
http://hg.python.org/cpython/rev/bdad5bc9a2ed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:17 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-SA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1b3c21b12e92 by ?ric Araujo in branch '3.1':
Remove mentions of previous license in profile module docs (#12417 followup).
http://hg.python.org/cpython/rev/1b3c21b12e92

New changeset 0fbc56b53848 by ?ric Araujo in branch '3.2':
Merge profile docs followup (#12417) from 3.1
http://hg.python.org/cpython/rev/0fbc56b53848

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:18 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-Rp@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 65d5ecefd50d by ?ric Araujo in branch '3.2':
Fix missing or wrong shebangs and missing executable bits for scripts (#10318)
http://hg.python.org/cpython/rev/65d5ecefd50d

New changeset 5467abaaf5eb by ?ric Araujo in branch 'default':
Merge from 3.2 (#10318, #12255, #12043, #12417 and other fixes)
http://hg.python.org/cpython/rev/5467abaaf5eb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:18 +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: <E1QmmHb-0003sf-SG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7f606223578a by ?ric Araujo in branch 'default':
Remove indirection in threading (issue #10968).
http://hg.python.org/cpython/rev/7f606223578a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:20 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-S3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5966eeb0457d by ?ric Araujo in branch 'default':
Add shlex.quote function, to escape filenames and command lines (#9723).
http://hg.python.org/cpython/rev/5966eeb0457d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:20 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-SU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 998566bf7fba by ?ric Araujo in branch 'default':
Let all pysetup actions return a meaningful 0 or 1 exit code (#12222).
http://hg.python.org/cpython/rev/998566bf7fba

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12222>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:21 +0000
Subject: [issue11409] pysetup --search should return non-zero when a dist is
	not installed and print a message stating the fact.
In-Reply-To: <1299349750.25.0.306966867422.issue11409@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-Sh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 88545218e155 by ?ric Araujo in branch 'default':
Let pysetup list exit with a non-zero code when no result is found (#11409).
http://hg.python.org/cpython/rev/88545218e155

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11409>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:21 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-SO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 836548ce4cd2 by ?ric Araujo in branch '3.2':
Update documentation for shutil.move (#12043) and fix a few typos.
http://hg.python.org/cpython/rev/836548ce4cd2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:35:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:35:22 +0000
Subject: [issue12542] Remove duplicates of cmp_to_key used in tests
In-Reply-To: <1310479186.26.0.28744944835.issue12542@psf.upfronthosting.co.za>
Message-ID: <E1QmmHb-0003sf-Sa@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fefb7d355361 by ?ric Araujo in branch '3.2':
Remove duplicates of cmp_to_key (#12542, reviewed by Raymond Hettinger)
http://hg.python.org/cpython/rev/fefb7d355361

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12542>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:37:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:37:58 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <E1QmmKC-000445-Fm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9356d2d61e9f by ?ric Araujo in branch '2.7':
Make VCSes ignore the compiled shared library file (#12255)
http://hg.python.org/cpython/rev/9356d2d61e9f

New changeset 4e5127874adf by ?ric Araujo in branch '2.7':
Stop ignoring Mercurial merge conflits files (#12255).
http://hg.python.org/cpython/rev/4e5127874adf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:37:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:37:58 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <E1QmmKC-000445-Fg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6bf168b55d07 by ?ric Araujo in branch '2.7':
Update documentation for shutil.move (#12043) and fix a few typos.
http://hg.python.org/cpython/rev/6bf168b55d07

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:37:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:37:59 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <E1QmmKC-000445-Fs@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b9a95ce2692c by ?ric Araujo in branch '2.6':
Remove mentions of previous license in profile module (#12417 followup)
http://hg.python.org/cpython/rev/b9a95ce2692c

New changeset 25a496966ecf by ?ric Araujo in branch '2.7':
Merge #12417 followup, also removing an extra docstring
http://hg.python.org/cpython/rev/25a496966ecf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:37:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 12:37:59 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <E1QmmKC-000445-FX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7fb0abf928e0 by ?ric Araujo in branch '2.7':
Fix missing or shebangs and executable bits for scripts (#10318)
http://hg.python.org/cpython/rev/7fb0abf928e0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:39:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 12:39:55 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311943195.13.0.16299724648.issue12531@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me.

One tip for commits: it?s often better to let a line exceed 80 characters in order to make for a smaller diff.  Here, only one word was changed but four lines were marked as changed, which makes reviews longer.  Lines are rewrapped when doing larger rewritings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:41:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 12:41:17 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1311943277.09.0.170222328256.issue11699@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yep, the ?to? is already present before the verb :)

I think we mark None as ``None``, not *None*.  (If the rest of the file does otherwise, then do that.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:42:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 12:42:43 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311943363.69.0.152892279212.issue10639@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree that using globals instead function arguments sucks, but let?s fix this bug without rewriting the whole file (unless this affects only the code new in 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:43:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 12:43:57 +0000
Subject: [issue11472] upload command fails to read auth information from
	.pypirc
In-Reply-To: <1299882429.66.0.49580074551.issue11472@psf.upfronthosting.co.za>
Message-ID: <1311943437.23.0.8471102734.issue11472@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you set DISTUTILS_DEBUG in your environment, retry to run the command and post the output?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11472>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:45:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 12:45:32 +0000
Subject: [issue12654] sum() works with bytes objects
In-Reply-To: <1311943531.95.0.378108563398.issue12654@psf.upfronthosting.co.za>
Message-ID: <1311943531.95.0.378108563398.issue12654@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

... while it apparently shouldn't:

>>> sum([b'', b''], b'')
b''
>>> sum([b'', b''], bytearray())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sum() can't sum bytes [use b''.join(seq) instead]


In 2.7, the situation is the reverse:

>>> sum([b'', b''], b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sum() can't sum strings [use ''.join(seq) instead]
>>> sum([b'', b''], bytearray())
bytearray(b'')

----------
components: Interpreter Core
messages: 141363
nosy: mark.dickinson, pitrou, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: sum() works with bytes objects
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12654>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:46:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 12:46:07 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311943567.71.0.036267378413.issue12531@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric - when I was just starting contributing patches to Python, I was strictly disciplined by veteran devs to stay within 80 chars no matter what :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:48:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 12:48:58 +0000
Subject: [issue12255] A few changes to .*ignore
In-Reply-To: <1307119345.93.0.971452096543.issue12255@psf.upfronthosting.co.za>
Message-ID: <1311943738.29.0.911130806231.issue12255@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is also fixed in 3.3, but I missed a reference in the merge commit message.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12255>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:51:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 12:51:25 +0000
Subject: [issue12417] Inappropriate copyright on profile files
In-Reply-To: <1309159902.95.0.523889608619.issue12417@psf.upfronthosting.co.za>
Message-ID: <1311943885.25.0.580828643648.issue12417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Of course, I had all 2.6 and 3.1 changesets in my existing clones :)  I committed my patch to all branches.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12417>
_______________________________________

From report at bugs.python.org  Fri Jul 29 14:59:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 12:59:22 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1311944362.59.0.890171167811.issue12562@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, pitrou, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12562>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:10:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 13:10:06 +0000
Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311945006.63.0.980037423706.issue12643@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If someone is setting sys.excepthook, they are not expecting it to be ignored, so I think there's no reason to preserve existing behaviour. On the other hand, it is easy to customize exception printout by subclassing InteractiveConsole and overriding the showtraceback() method.

aliles, if you want to work on a patch, we have a developer's guide at http://docs.python.org/devguide/.

----------
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12643>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:10:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 13:10:19 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <E1QmmpW-0006uj-JW@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 43c41e19527a by ?ric Araujo in branch 'default':
Expand shlex.quote example (#9723)
http://hg.python.org/cpython/rev/43c41e19527a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:11:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 13:11:44 +0000
Subject: [issue12643] code.InteractiveConsole ignores sys.excepthook
In-Reply-To: <1311768607.53.0.760039078139.issue12643@psf.upfronthosting.co.za>
Message-ID: <1311945104.92.0.296053401675.issue12643@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Another possibility yet is to add an "excepthook" argument to the InteractiveInterpreter / InteractiveConsole constructors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12643>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:16:57 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 29 Jul 2011 13:16:57 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311945417.29.0.84539723312.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The 'spec_newline' in particular is only in the trunk (not in the backports), as it's part of the new --newline option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:18:55 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 29 Jul 2011 13:18:55 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311945535.33.0.314451391795.issue10639@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Jason, one way or another, a prompt fix for trunk is required, since `make patchcheck` is an important step for committing patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:33:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Jul 2011 13:33:20 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1311946400.87.0.272839795088.issue670664@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It sounds like the early consensus on python-dev is that html5 support is a good thing.  I'm happy with that.  I presume that means the 'strict' keyword in 3.x becomes strict-per-html5, and possibly useless :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:33:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 13:33:50 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <E1QmnCF-0000Q2-9x@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2547f7965733 by Jason R. Coombs in branch 'default':
Issue #10639: spec_newline wasn't defined globally unless main() was called; now spec_newline is set at module import/execution
http://hg.python.org/cpython/rev/2547f7965733

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:35:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:35:58 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1311946558.32.0.264444089228.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I suck at regexes, but the one I came up with lets quote pass the tests that existed for pipes.quote, so I figure it?s good.  I did not change the string operations at the end of the function (+ and replace) as it was simple and working.

In the absence of review or opposition here, I have committed my patch.  Feedback welcome.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:36:52 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 29 Jul 2011 13:36:52 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311946612.84.0.401476145205.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I hadn't realized that the other global variables were defined at the module level or I would have implemented this originally. Please let me know if this patch doesn't correct the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:38:51 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 29 Jul 2011 13:38:51 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1311946731.72.0.68107915844.issue10639@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
stage: needs patch -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:40:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:40:43 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1311946843.88.0.302838747036.issue12043@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:45:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:45:13 +0000
Subject: [issue11409] pysetup --search should return non-zero when a dist is
	not installed and print a message stating the fact.
In-Reply-To: <1299349750.25.0.306966867422.issue11409@psf.upfronthosting.co.za>
Message-ID: <1311947113.96.0.206969191749.issue11409@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adapted and committed.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -3rd party, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11409>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:47:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:47:45 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <1311947265.49.0.0355517279121.issue12222@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I committed my patch, except for one change in the run action.  It returns the dist.Distribution instance, which is needed by test_uninstall and not trivial to fix.  I tried changing the code to use Distribution and command objects directly but suddenly the --prefix option was not respected, so I stopped after a few tries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12222>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:47:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Jul 2011 13:47:50 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1311947270.24.0.221624297518.issue9723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry I didn't look at the patch earlier.  I thought we were just *moving* pipes.quote.  Why is a new regex involved?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:47:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:47:59 +0000
Subject: [issue12542] Remove duplicates of cmp_to_key used in tests
In-Reply-To: <1310479186.26.0.28744944835.issue12542@psf.upfronthosting.co.za>
Message-ID: <1311947279.48.0.448262209849.issue12542@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12542>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:51:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:51:58 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1311947518.89.0.0938178796198.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Because I choose to follow Ian?s remark in msg127957:
> the implementation could use a couple regexes instead of iterating
> over strings though

I have not touched the tests, so I felt confident with my regex.  FWIW, I?ve also changed the argument name, since the function is not limited to file names (as I hopefully made clear in the doc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:52:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:52:42 +0000
Subject: [issue1284670] Allow to restrict ModuleFinder to get "direct"
	dependencies
Message-ID: <1311947562.8.0.288220988559.issue1284670@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22686/modulefinder-no-recurse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284670>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:53:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:53:58 +0000
Subject: [issue1284670] Allow to restrict ModuleFinder to get "direct"
	dependencies
Message-ID: <1311947638.58.0.659187175584.issue1284670@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I modernized modulefinder a bit in 1521d9837d16; here?s a refreshed patch.

----------
Added file: http://bugs.python.org/file22792/modulefinder-no-recurse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284670>
_______________________________________

From report at bugs.python.org  Fri Jul 29 15:54:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 13:54:53 +0000
Subject: [issue11827] mention of list2cmdline() in docs of subprocess.Popen
In-Reply-To: <1302511097.53.0.993242324349.issue11827@psf.upfronthosting.co.za>
Message-ID: <1311947693.76.0.928697220357.issue11827@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The module docstring (which duplicates the reST docs) still mentions list2cmdline.  I?d vote for removal there too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11827>
_______________________________________

From report at bugs.python.org  Fri Jul 29 16:44:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Jul 2011 14:44:26 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1311950666.06.0.132912593311.issue9723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it's a micro-optimization (it would be interesting to benchmark, but not worth it).  I find the original code much more readable than the regex, but it doesn't matter all that much.  (And as far as optimization goes, using translate might be even faster.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 16:47:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 14:47:49 +0000
Subject: [issue12112] The new packaging module should not use the locale
	encoding
In-Reply-To: <1305806068.46.0.0788802994526.issue12112@psf.upfronthosting.co.za>
Message-ID: <1311950869.61.0.721721102556.issue12112@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can run LANG=C python -m test test_packaging successfully.  Can we close this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Fri Jul 29 16:48:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 14:48:56 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1311950936.76.0.0744761848988.issue12167@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I edited my patch to use a copy instead of an explicit empty dict, but I found a bug.  The restore code unpacks the saved_caches object to (cache, items), but saved_caches is (id(cache), cache, cache.copy()).  I?m surprised the unpacking works; I don?t want to commit before I understand that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:11:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 15:11:50 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1311952310.45.0.546663565149.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

str.translate is not an option, as the code does not replace but add characters (quotes).

Out of sheer curiosity, I may actually benchmark this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:20:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Jul 2011 15:20:13 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1311952813.69.0.67825707355.issue9723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You aren't using a regex to replace the quotes, either.

>>> len('abcd'.translate(str.maketrans('', '', string.ascii_letters ))) > 0
False

I don't know if this is faster than the corresponding search regex, but depending on how much overhead regex has, it might be.  Note that the translate table can be pre-built, just like the compiled regex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:36:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 15:36:34 +0000
Subject: [issue8887] "pydoc str" works but not "pydoc str.translate"
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <E1Qmp72-0003VH-Nd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 68df566cbf92 by ?ric Araujo in branch '2.7':
Make ?pydoc somebuiltin.somemethod? work (#8887)
http://hg.python.org/cpython/rev/68df566cbf92

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:38:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 15:38:43 +0000
Subject: [issue8887] "pydoc str" works but not "pydoc str.translate"
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <E1Qmp98-0003bh-Kh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f02a8f906342 by ?ric Araujo in branch '3.2':
Make ?pydoc somebuiltin.somemethod? work (#8887)
http://hg.python.org/cpython/rev/f02a8f906342

New changeset 91d6cabf77d6 by ?ric Araujo in branch 'default':
Merge fix for #8887 from 3.2
http://hg.python.org/cpython/rev/91d6cabf77d6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:39:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 15:39:33 +0000
Subject: [issue8887] "pydoc str" works but not "pydoc str.translate"
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1311953973.26.0.123628161302.issue8887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks again for the useful review.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:47:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 15:47:40 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1311954460.57.0.625828303232.issue12648@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12648>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:48:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 15:48:00 +0000
Subject: [issue12653] Provide accelerators for all buttons in Windows
	installers
In-Reply-To: <1311935783.8.0.769443256699.issue12653@psf.upfronthosting.co.za>
Message-ID: <1311954480.5.0.856871166346.issue12653@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +loewis
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12653>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:54:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 15:54:45 +0000
Subject: [issue9254] __import__ docstring should recommend
	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <1311954885.21.0.44242871417.issue9254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch committed in 3.2.

Attached patch ports the docstring change to 2.7 and edits the reST docs, please approve.

----------
assignee: docs at python -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9254>
_______________________________________

From report at bugs.python.org  Fri Jul 29 17:55:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 15:55:43 +0000
Subject: [issue9254] __import__ docstring should recommend
	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <1311954943.5.0.179958834823.issue9254@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22793/__import__-mention-importlib-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9254>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:11:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 16:11:13 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <E1Qmpea-0006ma-3c@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e37fa30c4be4 by ?ric Araujo in branch '3.2':
Document that atexit execution order is undefined (#9788)
http://hg.python.org/cpython/rev/e37fa30c4be4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:11:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 16:11:13 +0000
Subject: [issue9254] __import__ docstring should recommend
	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <E1Qmpea-0006ma-3k@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7bfc0a45542c by ?ric Araujo in branch '3.2':
Let the doc of __import__ link to importlib (#9254).
http://hg.python.org/cpython/rev/7bfc0a45542c

New changeset 4a6cb2d9e906 by ?ric Araujo in branch 'default':
Merge from 3.2 (#9254, #8982, #9788)
http://hg.python.org/cpython/rev/4a6cb2d9e906

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9254>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:11:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 16:11:14 +0000
Subject: [issue8982] argparse docs cross reference Namespace as a class but
	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <E1Qmpea-0006ma-4o@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 939631c6bc6f by ?ric Araujo in branch '3.2':
Add a link target for argparse.Namespace (#8982)
http://hg.python.org/cpython/rev/939631c6bc6f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8982>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:13:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 16:13:47 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <E1Qmph4-0006zR-Ds@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset df415bfbb652 by ?ric Araujo in branch '2.7':
Document that atexit execution order is undefined (#9788)
http://hg.python.org/cpython/rev/df415bfbb652

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:13:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 16:13:47 +0000
Subject: [issue8982] argparse docs cross reference Namespace as a class but
	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <E1Qmph4-0006zR-E8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 01722022f88d by ?ric Araujo in branch '2.7':
Add a link target for argparse.Namespace (#8982)
http://hg.python.org/cpython/rev/01722022f88d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8982>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:19:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 16:19:16 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1311956356.47.0.217635324352.issue9788@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Given Benjamin and Giampaolo?s support, I committed my patch, so that at least the current behavior is documented.  I personally have no opinion on LIFO vs. FIFO vs. undefined; I just think that the atexit module is not a wrapper around C?s atexit, and as such not bound by the same rules, and undefined sounds fine.  If you feel very strongly about that, then please follow up on python-dev.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:23:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 16:23:03 +0000
Subject: [issue12618] py_compile cannot create files in current directory
In-Reply-To: <1311406971.17.0.312082121474.issue12618@psf.upfronthosting.co.za>
Message-ID: <1311956583.51.0.337856693629.issue12618@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +eric.araujo
stage:  -> test needed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12618>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:23:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 16:23:25 +0000
Subject: [issue12622] failfast argument to TextTestRunner not documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1311956605.0.0.982617134939.issue12622@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12622>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:24:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 16:24:19 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1311956659.71.0.234414271635.issue12626@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d love this in regrtest and unittest.

----------
nosy: +eric.araujo
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:24:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 16:24:57 +0000
Subject: [issue12629] HTMLParser silently stops parsing with malformed
	attributes
In-Reply-To: <1311532507.83.0.00235537878353.issue12629@psf.upfronthosting.co.za>
Message-ID: <1311956697.68.0.508106078685.issue12629@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12629>
_______________________________________

From report at bugs.python.org  Fri Jul 29 18:27:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Jul 2011 16:27:50 +0000
Subject: [issue12633] sys.modules doc entry should reflect restrictions
In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>
Message-ID: <1311956870.09.0.481359633569.issue12633@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The note?s spirit is good, but I think something more concise would do.

Side note: Please don?t mix up unrelated cosmetic changes in your diffs.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12633>
_______________________________________

From report at bugs.python.org  Fri Jul 29 19:00:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 17:00:23 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <E1QmqQ9-0002p1-W9@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5f7e71cfbcd6 by Charles-Fran?ois Natali in branch '3.2':
Issue #12464: tempfile.TemporaryDirectory.cleanup() should not follow symlinks:
http://hg.python.org/cpython/rev/5f7e71cfbcd6

New changeset c0bae008df81 by Charles-Fran?ois Natali in branch 'default':
Issue #12464: tempfile.TemporaryDirectory.cleanup() should not follow symlinks:
http://hg.python.org/cpython/rev/c0bae008df81

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Fri Jul 29 19:09:56 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Jul 2011 17:09:56 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

For fun and profit. :)

----------
components: Extension Modules
files: sched_stuff.patch
keywords: patch
messages: 141401
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: Expose sched.h functions
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22794/sched_stuff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Fri Jul 29 19:48:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Jul 2011 17:48:56 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1311961736.02.0.799419852457.issue12655@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> @@ -10330,26 +10899,34 @@ INITFUNC(void)
I know that it's only an increase of 5%, but I feel that posixmodule.c is already large enough.
Does this feature belongs to the os module?
Or is it time to split posixmodule.c in several pieces?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Fri Jul 29 19:50:16 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Jul 2011 17:50:16 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311961736.02.0.799419852457.issue12655@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o-XOj=mLj1tkGP+RSu8z3O_Op4X9YYtvSu+yq6H7hgNQw@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/29 Amaury Forgeot d'Arc <report at bugs.python.org>:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
>> @@ -10330,26 +10899,34 @@ INITFUNC(void)
> I know that it's only an increase of 5%, but I feel that posixmodule.c is already large enough.
> Does this feature belongs to the os module?
> Or is it time to split posixmodule.c in several pieces?

I completely agree with you, but that's a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Fri Jul 29 20:00:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 29 Jul 2011 18:00:09 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

As noted in issue #12502, test_asyncore only tests AF_INET sockets.
With the patch attached, the vast majority of the tests will also be run with AF_UNIX and AF_INET6 sockets (if supported by the host OS).

----------
components: Tests
files: test_ayncore.diff
keywords: needs review, patch
messages: 141404
nosy: giampaolo.rodola, neologix
priority: low
severity: normal
stage: patch review
status: open
title: test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22795/test_ayncore.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Fri Jul 29 20:24:53 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 29 Jul 2011 18:24:53 +0000
Subject: [issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic
	links
In-Reply-To: <1309523445.96.0.359988980171.issue12464@psf.upfronthosting.co.za>
Message-ID: <1311963893.94.0.321642361251.issue12464@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed.
Petri, thanks for the patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12464>
_______________________________________

From report at bugs.python.org  Fri Jul 29 20:28:08 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Jul 2011 18:28:08 +0000
Subject: [issue12657] Cannot override JSON encoding of basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

I found this out while experimenting with enum types that inherit from int.  The json library provides for extending the encoder to handle non-basic types; in those cases, your class's .default() method is called.  However, it is impossible to override how basic types are encoded.

Worse, if you subclass int, you cannot override how instances of your subclass get encoded, because _iterencode() does isinstance() checks.  So enum values which subclass int cannot be properly encoded.

I think the isinstance checks should be changed to explicit type equality tests, e.g. `type(o) is int`.

----------
components: Library (Lib)
messages: 141406
nosy: barry
priority: normal
severity: normal
status: open
title: Cannot override JSON encoding of basic type subclasses
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12657>
_______________________________________

From report at bugs.python.org  Fri Jul 29 20:40:45 2011
From: report at bugs.python.org (phep)
Date: Fri, 29 Jul 2011 18:40:45 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311964845.59.0.0537025664398.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

These are the changeset details:
changeset:   18337:c2a60de91d2c
branch:      legacy-trunk
user:        Guido van Rossum <guido at python.org>
date:        Fri Jun 29 13:06:06 2001 +0000
summary:     Solve SF bug #231249: cgi.py opens too many (temporary) files.


You're right that we might use environment variables or tempfile.tempdir
to attain the same goal but this would impact _all_ of the code executed
during request data parsing given the monolithic construction of
FieldStorage. This implies that the context of every call to tempfile
members would be impacted during this process.  Presently this is not a
problem at all, but this looks fragile for future developments. 

On the other hand:
1) this has the advantage of not changing FieldStorage interface,
2) this alleviates us of wondering if passing to FieldStorage
constructor all of the arguments to NamedTemporaryFile is a possibility
worth considering ;-).

After pondering this for a while I think the simpler is the better and I
propose to add documentation to inform the reader that changing the
temp directory through os.environ of tempfile.tempdir might worth
consideration.

As for other use cases for changing the temp directory, I thought about
letting the user choose the FS of its choice with regard to
performance or security (crypted FS) or even having the temp files created in a directory with 700 permissions. 

Last, you're perfectly right about the None argument.

I fiddled last night with setting an environment to deploy and test a patched Python (I had some problem to understand what happened when I encountered 6755). This now works and the patch does not introduced any regression. I still have to add unit tests (I only tested with my embryonic cgi script) and update the documentation before to send the patch. I should be able to do that in a few days at most.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Fri Jul 29 20:43:16 2011
From: report at bugs.python.org (phep)
Date: Fri, 29 Jul 2011 18:43:16 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1311964996.54.0.0973664510293.issue6755@psf.upfronthosting.co.za>


Changes by phep <patrice.pillot at teletopie.net>:


----------
nosy: +phep

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Fri Jul 29 21:24:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 19:24:43 +0000
Subject: [issue12654] sum() works with bytes objects
In-Reply-To: <1311943531.95.0.378108563398.issue12654@psf.upfronthosting.co.za>
Message-ID: <E1Qmsfp-0005kn-U7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7368d0e9b33e by Benjamin Peterson in branch 'default':
bytes should be verboten in sum() (fixes #12654)
http://hg.python.org/cpython/rev/7368d0e9b33e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12654>
_______________________________________

From report at bugs.python.org  Fri Jul 29 21:33:19 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 29 Jul 2011 19:33:19 +0000
Subject: [issue9788] atexit and execution order
In-Reply-To: <1283855234.53.0.604946356676.issue9788@psf.upfronthosting.co.za>
Message-ID: <1311967999.93.0.0594974035425.issue9788@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Thanks. After all, I think that "keeping atexit simple" is the best solution and a doc adjustement is just fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9788>
_______________________________________

From report at bugs.python.org  Fri Jul 29 21:59:11 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Jul 2011 19:59:11 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <1311969551.52.0.634654378507.issue12575@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It'd be nice to get this in soon, so phase 2 can begin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12575>
_______________________________________

From report at bugs.python.org  Fri Jul 29 23:08:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Jul 2011 21:08:35 +0000
Subject: [issue12654] sum() works with bytes objects
In-Reply-To: <1311943531.95.0.378108563398.issue12654@psf.upfronthosting.co.za>
Message-ID: <1311973715.83.0.8097286651.issue12654@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12654>
_______________________________________

From report at bugs.python.org  Fri Jul 29 23:32:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 21:32:04 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1311975124.95.0.385243276581.issue12655@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Haven't reviewed the implementation, but +1 for adding this functionality.

As for splitting apart posixmodule.c, I agree that's a separate concern. Something like the _io module splitup (several C files compiled in a single extension module) looks workable.

We could also consider having a separate module for this, but I can't think of any good name. "sched" is AFAIK already taken, and "scheduler" is too close to the former not to be confusing.

----------
nosy: +neologix, rosslagerwall
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Fri Jul 29 23:50:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 29 Jul 2011 21:50:47 +0000
Subject: [issue12652] Move documentation of test.support into the devguide
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1311976247.38.0.978742799076.issue12652@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/issue12652>
_______________________________________

From report at bugs.python.org  Fri Jul 29 23:58:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Jul 2011 21:58:55 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <E1Qmv53-00012V-LS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d7a2bd9a3d1 by Antoine Pitrou in branch '3.2':
Issue #12626: In regrtest, allow to filter tests using a glob filter
http://hg.python.org/cpython/rev/5d7a2bd9a3d1

New changeset 018e14a46454 by Antoine Pitrou in branch 'default':
Issue #12626: In regrtest, allow to filter tests using a glob filter
http://hg.python.org/cpython/rev/018e14a46454

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sat Jul 30 00:00:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jul 2011 22:00:29 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1311976829.15.0.500094269366.issue12626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a slightly updated patch that also works with -j.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sat Jul 30 00:42:09 2011
From: report at bugs.python.org (phep)
Date: Fri, 29 Jul 2011 22:42:09 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1311979329.46.0.944135973535.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

So, this is the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file22796/fix9968.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Sat Jul 30 00:54:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 29 Jul 2011 22:54:22 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311975124.95.0.385243276581.issue12655@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2EN2An2XJnZOT7bh3A21zSBNnBefYx+VBCM77-yXJy-A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm +0.
It would certainly be fun, but I'm not so sure about the "profit" part.
The main usage of the scheduler API is for real-time policies, and I
somehow doubt Python is commonly used in this area (but I could be
wrong).
Furthermore, the same functionality can be easily achieved with
schedtool/taskset.

Concerning the patch, I think that several constants ought to be
guarded by #ifdef's: only SCHED_(OTHER|FIFO|RR) are required by POSIX:
the other are Linux-specific (also, SCHED_BATCH, SCHED_IDLE and
SCHED_RESET_ON_FORK are only defined in recent Linux kernels, older
libcs probably don't define them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Sat Jul 30 01:30:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Jul 2011 23:30:26 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1311982226.99.0.0202064195754.issue12655@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I actually implemented this because I wanted to confine a Python process to a cpu to prevent keep it from being tossed from core to core. It made sense to bring the other scheduling functions along for the ride.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Sat Jul 30 01:37:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Jul 2011 23:37:44 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1311982664.12.0.32230240825.issue12655@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file22797/sched_stuff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Sat Jul 30 04:58:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jul 2011 02:58: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: <E1QmzlB-0005ab-UZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 26839edf3cc1 by Senthil Kumaran in branch 'default':
Fix closes Issue11281 - smtplib.STMP gets source_address parameter, which adds the ability to bind to specific source address on a machine with multiple interfaces. Patch by Paulo Scardine.
http://hg.python.org/cpython/rev/26839edf3cc1

----------
nosy: +python-dev
resolution: remind -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Sat Jul 30 05:52:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 03:52:30 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1311946612.84.0.401476145205.issue10639@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9UMHrL8Y6ZFGDe8k-p-NbVW-GA88Rj9Tus_BjzxEPEKg@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

"make patchcheck" is working again.
Thanks

----------
Added file: http://bugs.python.org/file22798/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________
-------------- next part --------------
<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
Jason R. Coombs &lt;<a href="mailto:jaraco at jaraco.com">jaraco at jaraco.com</a>&gt; added the comment:<br>
<br>
</div>I hadn&#39;t realized that the other global variables were defined at the module level or I would have implemented this originally. Please let me know if this patch doesn&#39;t correct the issue.<br>
<div><div></div><br></div></blockquote></div><br>&quot;make patchcheck&quot; is working again. <br>Thanks<br></div>

From report at bugs.python.org  Sat Jul 30 06:09:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jul 2011 04:09:40 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <E1Qn0rq-000249-Eo@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a8aa918041c2 by Eli Bendersky in branch '3.2':
Issue #12531: add index entries to documentation of * and ** in function calls
http://hg.python.org/cpython/rev/a8aa918041c2

New changeset 221ca00121ef by Eli Bendersky in branch 'default':
Merge from 3.2: Issue #12531: add index entries to documentation of * and ** in function calls
http://hg.python.org/cpython/rev/221ca00121ef

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Sat Jul 30 06:10:19 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 04:10:19 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1311999019.03.0.264843689353.issue12531@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Sat Jul 30 06:13:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 04:13:44 +0000
Subject: [issue12380] bytearray methods center, ljust,
	rjust don't accept a bytearray as the fill character
In-Reply-To: <1308628210.93.0.613061897988.issue12380@psf.upfronthosting.co.za>
Message-ID: <1311999224.99.0.285851109649.issue12380@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________

From report at bugs.python.org  Sat Jul 30 06:32:00 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 04:32:00 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1312000320.14.0.757178640718.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching an initial patch for Lib/idlelib/PyShell.py

It uses subprocess.Popen instead of spawn&kill, in the way discussed in earlier messages. 

As far as I can tell, IDLE opens and restarts shells successfully, without leaving zombies behind. I only tested it on Windows, however, and due to the lack of unit tests for idlelib there wasn't much verification done.

----------
keywords: +patch
Added file: http://bugs.python.org/file22799/issue12540.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 30 06:49:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 30 Jul 2011 04:49:27 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1312001367.01.0.887735348959.issue12611@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Still cannot reproduce with the linked file. Setting as pending until we hear the details from Vladimir.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12611>
_______________________________________

From report at bugs.python.org  Sat Jul 30 06:49:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 04:49:38 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1312001378.35.0.483164508559.issue12540@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I've now tested this on Ubuntu Linux as well. IDLE works, no zombies left behind.

----------
keywords:  -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________

From report at bugs.python.org  Sat Jul 30 07:08:38 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 30 Jul 2011 05:08:38 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1312002518.22.0.384569402762.issue11699@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Updated the patch:

- Removed the extra "to"

- Changed *None* to ``None`` for conformance with the rest of the file

The same patch applies unmodified to 2.7 and 3.2 branches.

----------
Added file: http://bugs.python.org/file22800/issue11699.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 07:08:49 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 30 Jul 2011 05:08:49 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1312002529.15.0.00808400184969.issue11699@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Removed file: http://bugs.python.org/file22785/issue11699.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 07:12:41 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 05:12:41 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1312002761.74.0.872511666734.issue11699@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Armin, adding you as the optparse expert - could you see the doc change makes sense?

[I will then do the commit work]

----------
nosy: +aronacher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 08:08:15 2011
From: report at bugs.python.org (Brian Thorne)
Date: Sat, 30 Jul 2011 06:08:15 +0000
Subject: [issue12428] functools test coverage
In-Reply-To: <1309255638.21.0.342456839611.issue12428@psf.upfronthosting.co.za>
Message-ID: <1312006095.42.0.353544736983.issue12428@psf.upfronthosting.co.za>


Brian Thorne <hardbyte at gmail.com> added the comment:

Cheers for the comments Eric. I've modified the patch accordingly.

----------
Added file: http://bugs.python.org/file22801/functools2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12428>
_______________________________________

From report at bugs.python.org  Sat Jul 30 09:04:30 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jul 2011 07:04:30 +0000
Subject: [issue12652] Move documentation of test.support into the devguide
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1312009470.16.0.609691206614.issue12652@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

-1 from me as well.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12652>
_______________________________________

From report at bugs.python.org  Sat Jul 30 09:07:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jul 2011 07:07:34 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1312009654.0.0.147721282995.issue11699@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It does make sense, please commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 09:09:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Jul 2011 07:09:16 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1312009756.31.0.110456823627.issue670664@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

As I said somewhere else, the only use case I can think of where the 'strict' flag is useful is validation, but AFAIK even in "strict mode" it's possible to parse non-valid documents, so I agree it's pretty useless.

Moving to HTML5 and offering something able to parse real-world HTML seems the way to go IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Sat Jul 30 09:10:12 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jul 2011 07:10:12 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1312009812.59.0.32675893214.issue11797@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I sure didn't have anything to do with that file :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Sat Jul 30 09:20:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Jul 2011 07:20:17 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1312010417.59.0.384316359522.issue9723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+_find_unsafe = re.compile(r'[^\w\d@%_\-\+=:,\./]').search

\w already includes both \d and _, so (unless you really want to be explicit about it) they are redundant.  Also keep in mind that they match non-ASCII letters/numbers on Python 3.
'+' and '.' don't need to be escaped in a character class (i.e. [...]), because they lose their meta-characters meaning there.
'-' is correctly escaped there, but it's common practice to place it at the end of the character class, where it doesn't need escaping.

r'[^\w\d@%_\-\+=:,\./]' and r'[^\w@%+=:,./-]' should therefore be equivalent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Sat Jul 30 10:14:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jul 2011 08:14:57 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <E1Qn4hD-0000FS-LA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5a248fcfa112 by Eli Bendersky in branch '2.7':
Issue #11699: fix documentation of OptionParser.get_option_group. Patch by Petri Lehtinen
http://hg.python.org/cpython/rev/5a248fcfa112

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 10:37:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 30 Jul 2011 08:37:40 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311982226.99.0.0202064195754.issue12655@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0TMVODcCB71F1Waq69iCz7id=BY1RKEsSHWtN0tdj+Mg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I actually implemented this because I wanted to confine a Python process to a cpu to prevent keep it from being tossed from core to core. It made sense to bring the other scheduling functions along for the ride.

Why didn't you use something like:

$ taskset <cpu mask> python myscript.py

By the way, binding a multi-threaded Python process to a single core
is often a simple way to improve performance, because with the GIL the
threads are actually serialized, so you have almost no contention, and
your threads get hot cache.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Sat Jul 30 10:39:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jul 2011 08:39:45 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <E1Qn55E-0001X3-8W@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cfb60dfa7734 by Eli Bendersky in branch '3.2':
Issue #11699: fix documentation of OptionParser.get_option_group. Patch by Petri Lehtinen
http://hg.python.org/cpython/rev/cfb60dfa7734

New changeset 27b588dd6155 by Eli Bendersky in branch 'default':
Merge 3.2: Issue #11699: fix documentation of OptionParser.get_option_group. Patch by Petri Lehtinen
http://hg.python.org/cpython/rev/27b588dd6155

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 10:43:31 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 08:43:31 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1312015411.81.0.951936522759.issue11699@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Done. 

Petri - thanks for the contribution.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 10:50:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jul 2011 08:50:55 +0000
Subject: [issue12658] Build fails in a non-checkout directory
Message-ID: <1312015855.7.0.362481082531.issue12658@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: pitrou
priority: normal
severity: normal
status: open
title: Build fails in a non-checkout directory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12658>
_______________________________________

From report at bugs.python.org  Sat Jul 30 11:01:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jul 2011 09:01:04 +0000
Subject: [issue12658] Build fails in a non-checkout directory
Message-ID: <1312016464.73.0.64413867142.issue12658@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/issue12658>
_______________________________________

From report at bugs.python.org  Sat Jul 30 12:41:45 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 30 Jul 2011 10:41:45 +0000
Subject: [issue11679] readline interferes with characters beginning with byte
	\xe9
In-Reply-To: <1301099319.36.0.392064400408.issue11679@psf.upfronthosting.co.za>
Message-ID: <1312022505.54.0.550963419655.issue11679@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

You're binding the M-i keyboard sequence. Could it be that the \xe9 byte is translated by the terminal to M-i, and that causes the interference? In this case, it's not really a bug.

----------
nosy: +petri.lehtinen
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11679>
_______________________________________

From report at bugs.python.org  Sat Jul 30 12:44:38 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 30 Jul 2011 10:44:38 +0000
Subject: [issue11640] Shelve references globals in its __del__ method
In-Reply-To: <1300832144.38.0.133902930927.issue11640@psf.upfronthosting.co.za>
Message-ID: <1312022678.11.0.64079209757.issue11640@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The patch looks good to me. Is there any way this could be tested in the test suite? How to simulate interpreter shutdown?

----------
keywords: +needs review -patch
nosy: +petri.lehtinen
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11640>
_______________________________________

From report at bugs.python.org  Sat Jul 30 14:10:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 30 Jul 2011 12:10:27 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1312027827.64.0.698003876576.issue12656@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22802/test_ayncore.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Sat Jul 30 14:10:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 30 Jul 2011 12:10:38 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1312027838.98.0.99574603976.issue12656@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22795/test_ayncore.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Sat Jul 30 14:50:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 12:50:50 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1312030250.2.0.0548751406342.issue12626@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I didn?t think this would go into a stable version (see #10849 for example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sat Jul 30 14:54:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jul 2011 12:54:04 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1312030444.04.0.170656800568.issue12626@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, let's say I don't consider test.regrtest, and especially its myriad options, a public API. The aim is to make bug diagnosis and fixing easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:06:24 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 30 Jul 2011 13:06:24 +0000
Subject: [issue12657] Cannot override JSON encoding of basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1312031184.0.0.0099508920434.issue12657@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/issue12657>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:16:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:16:22 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1312031782.38.0.884068442338.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> \w already includes both \d and _, so (unless you really want to be
> explicit about it) they are redundant. [snip]
I just started from the previous list and turned it into a regex.  Eliminating redundancy sounds good, I?ll use your version.

> Also keep in mind that they match non-ASCII letters/numbers on
> Python 3.
This was not covered by the previous tests, but I think it?s fine: the shell is concerned about some metacharacters and spaces, not Unicode letters.  To be 100% sure, I will add tests with Unicode characters for pipes.quote in 3.2, and when merging with 3.3 I?ll know if the new code still complies.

----------
stage: committed/rejected -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:30:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:30:30 +0000
Subject: [issue11699] Doc for optparse.OptionParser.get_option_group is wrong
In-Reply-To: <1301301829.71.0.0713641718569.issue11699@psf.upfronthosting.co.za>
Message-ID: <1312032630.8.0.440155893443.issue11699@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11699>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:32:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:32:06 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <1312032726.82.0.565303066659.issue12531@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:32:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:32:29 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1312032749.55.0.900102266475.issue10639@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22798/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:45:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:45:20 +0000
Subject: [issue9968] cgi.FieldStorage: Give control about the directory used
	for uploads
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1312033520.91.0.700156512253.issue9968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> After pondering this for a while I think the simpler is the better
> and I propose to add documentation to inform the reader that changing
> the temp directory through os.environ of tempfile.tempdir might worth
> consideration.
Okay.  Your patch has this doc change and also code changes.

I?ve read in the tempfile module docstring that in order to control the directory, you have to set tempfile.tempdir before calling any tempfile function.  I suspect this will not be okay for some applications.  I wonder if the same limitation applies when one sets os.environ['TMP'].

In the light of that, do you think the tempfile solution is enough, or do you want to get back to the earlier idea of adding an argument to FieldStorage?

(One advantage of doc changes is that they can get committed to 2.7, 3.2 and 3.3 and get published immediately.  We can anyway make a code change in 3.3 and a doc change for older versions.)

> As for other use cases for changing the temp directory, I thought
> about letting the user choose the FS of its choice with regard to
> performance or security (crypted FS) or even having the temp files
> created in a directory with 700 permissions.
Excellent use cases.

> I fiddled last night with setting an environment to deploy and test a
> patched Python
Are you aware of the developers? guide?  http://docs.python.org/devguide/

> (I had some problem to understand what happened when I encountered
> 6755).
What is 6755?

----------
title: Let cgi.FieldStorage have named uploaded file -> cgi.FieldStorage: Give control about the directory used for uploads

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:48:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:48:49 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1312033729.21.0.877624244157.issue11049@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/issue11049>
_______________________________________

From report at bugs.python.org  Sat Jul 30 15:51:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Jul 2011 13:51:24 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Packaging?s test support module should have tests.

Using the ?easy? keyword because I?m willing to review and commit partial patches by new contributors instead of waiting for one complete patch.

----------
assignee: tarek
components: Distutils2
keywords: easy
messages: 141441
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: Add tests for packaging.tests.support
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Sat Jul 30 16:15:17 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 Jul 2011 14:15:17 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <CAH_1eM0TMVODcCB71F1Waq69iCz7id=BY1RKEsSHWtN0tdj+Mg@mail.gmail.com>
Message-ID: <CAPZV6o_RU4vQ2qN2N1ZbggzSk_2bJ0G=Y5xDwS6K+MPa7xyP3w@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/7/30 Charles-Fran?ois Natali <report at bugs.python.org>:
>
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
>
>> I actually implemented this because I wanted to confine a Python process to a cpu to prevent keep it from being tossed from core to core. It made sense to bring the other scheduling functions along for the ride.
>
> Why didn't you use something like:
>
> $ taskset <cpu mask> python myscript.py

Because I didn't want to type that every time I ran the script.

>
> By the way, binding a multi-threaded Python process to a single core
> is often a simple way to improve performance, because with the GIL the
> threads are actually serialized, so you have almost no contention, and
> your threads get hot cache.

Indeed, that's what I was doing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Sat Jul 30 17:06:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Jul 2011 15:06:49 +0000
Subject: [issue12660] test_gdb fails when installed
In-Reply-To: <1312038409.05.0.274432685937.issue12660@psf.upfronthosting.co.za>
Message-ID: <1312038409.05.0.274432685937.issue12660@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_gdb doesn't work from an installed Python 3.3. I suppose gdb fails finding the plugin file for the Python executable, although it manifests in quite mysterious ways. The log is rather large, I'm attaching it just in case.

----------
assignee: dmalcolm
components: Tests
files: test_gdb.log
messages: 141443
nosy: dmalcolm, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: test_gdb fails when installed
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22803/test_gdb.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12660>
_______________________________________

From report at bugs.python.org  Sat Jul 30 17:38:00 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 30 Jul 2011 15:38:00 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1312040280.03.0.299305836969.issue12183@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

When shutil.copy2 already says that it's behavior is equivalent to cp -p, will adding this sentence

+   Symbolic links are not preserved. The contents and metadata of the
+   linked files are copied instead.

Not actively confuse the user?  Because cp -p's behavior includes that and I dont see a special mention without giving more details is going to help.

The other portion of the patch seems okay to me.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12183>
_______________________________________

From report at bugs.python.org  Sat Jul 30 18:07:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Jul 2011 16:07:41 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312042061.93.0.943626094287.issue12648@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's actually the documentation that's slightly wrong in this case. On Windows, there is an additional import mechanism based on the Windows registry that is checked before the ordinary sys.path mechanism. (See http://docs.python.org/library/pkgutil#pkgutil.iter_importers)

The easiest way to check if this is happening is to see which version of the code is executed by "python -m parser". If I'm right, that will execute the local parser.py file on both Linux and Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12648>
_______________________________________

From report at bugs.python.org  Sat Jul 30 18:13:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Jul 2011 16:13:04 +0000
Subject: [issue12652] Keep test.support docs out of the global docs index
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1312042384.87.0.194476033191.issue12652@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Barry convinced me that the test.support docs need to stay in the same repo as the code they document, so -1 from me as well.

Changed issue title to reflect the real problem that inspired this suggestion (i.e. test.support.unlink et al appearing in the docs index alongside the actual functions they wrap).

Is there a :noindex: directive that will tell Sphinx not to index an entire section?

----------
title: Move documentation of test.support into the devguide -> Keep test.support docs out of the global docs index

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12652>
_______________________________________

From report at bugs.python.org  Sat Jul 30 19:11:04 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 17:11:04 +0000
Subject: [issue12652] Keep test.support docs out of the global docs index
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1312045864.16.0.755276909874.issue12652@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Nick, fair enough, but I think it would be more appropriate (and useful) to close this issue as rejected and open a new one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12652>
_______________________________________

From report at bugs.python.org  Sat Jul 30 19:16:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Jul 2011 17:16:53 +0000
Subject: [issue12652] Keep test.support docs out of the global docs index
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1312046213.52.0.6485259637.issue12652@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why is it more useful to open a new issue for the same problem?

Nick: there is no such option right now, but I can customize our Sphinx build so that test.support is ignored when building the index.  I'll do that if no better consensus is reached on python-dev soon.

----------
assignee:  -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12652>
_______________________________________

From report at bugs.python.org  Sat Jul 30 19:27:56 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 30 Jul 2011 17:27:56 +0000
Subject: [issue12652] Keep test.support docs out of the global docs index
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1312046876.07.0.635804915848.issue12652@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg, since the issue was originally opened to track the solution, not the problem, I just figured it may be useful to mention that this solution was rejected and close the issue, for better historical record. Otherwise some years from now no one will remember what the debate was and that the solution was overruled in favor of another.

It's just an opinion, though. I don't have strong feelings about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12652>
_______________________________________

From report at bugs.python.org  Sat Jul 30 19:52:52 2011
From: report at bugs.python.org (Leonid Vasilev)
Date: Sat, 30 Jul 2011 17:52:52 +0000
Subject: [issue12661] [new function] shutil.cleartree
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>


New submission from Leonid Vasilev <vsleonid at gmail.com>:

Hello,

This patch adds new function to shutil.
I think it's quite generic, and it fits shutil purpose.

Sample usage:
shutil.cleartree(path='/home/chin/Dev/python-hg-dev', ignore=shutil.ignore_pattterns('*.py'))

removes all files from path, except *.py files. 

and

shutil.cleartree(path='/home/chin/Dev/python-hg-dev', ignore=shutil.ignore_pattterns('*.pyc'), invert=True)

is equivalent to `find /home/chin/Dev/python-hg-dev -name "*.pyc" -delete`

----------
components: Library (Lib)
files: shutil.cleartree.patch
keywords: patch
messages: 141450
nosy: chin
priority: normal
severity: normal
status: open
title: [new function] shutil.cleartree
type: feature request
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22804/shutil.cleartree.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12661>
_______________________________________

From report at bugs.python.org  Sat Jul 30 20:31:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jul 2011 18:31:37 +0000
Subject: [issue12531] documentation index entries for * and **
In-Reply-To: <1310385823.58.0.152505903133.issue12531@psf.upfronthosting.co.za>
Message-ID: <E1QnEJz-0004nM-Ui@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8862ec62f9ee by Ezio Melotti in branch '3.2':
#12531: Fix spaces and markup.
http://hg.python.org/cpython/rev/8862ec62f9ee

New changeset b47c9982506c by Ezio Melotti in branch 'default':
#12531: merge with 3.2.
http://hg.python.org/cpython/rev/b47c9982506c

New changeset 952e83a8bc78 by Ezio Melotti in branch '2.7':
#12531: Fix spaces.
http://hg.python.org/cpython/rev/952e83a8bc78

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12531>
_______________________________________

From report at bugs.python.org  Sat Jul 30 22:32:17 2011
From: report at bugs.python.org (Laurie Clark-Michalek)
Date: Sat, 30 Jul 2011 20:32:17 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1312057937.7.0.259327595678.issue11797@psf.upfronthosting.co.za>


Laurie Clark-Michalek <bluepeppers at archlinux.us> added the comment:

Ah, that's my fault. As I mentioned, I simply replaced sys with imp and intern with reload from fix_intern.py. Seeing as the vast majority of the file was not modified, I didn't bother to change the copyright notices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Sun Jul 31 00:52:04 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 30 Jul 2011 22:52:04 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <1312066324.26.0.223298833598.issue12655@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file22805/sched_stuff.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12655>
_______________________________________

From report at bugs.python.org  Sun Jul 31 01:09:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Jul 2011 23:09:19 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <E1QnIej-0005di-Ok@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b76684d62a8d by Nadeem Vawda in branch 'default':
Issue #11651: Improve Makefile test targets.
http://hg.python.org/cpython/rev/b76684d62a8d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11651>
_______________________________________

From report at bugs.python.org  Sun Jul 31 02:30:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 Jul 2011 00:30:41 +0000
Subject: [issue12661] [new function] shutil.cleartree
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312072241.61.0.407879701748.issue12661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My immediate reaction is that this is too specialized.  We'll see what others think.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12661>
_______________________________________

From report at bugs.python.org  Sun Jul 31 03:36:11 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 31 Jul 2011 01:36:11 +0000
Subject: [issue12661] [new function] shutil.cleartree
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312076171.4.0.981685786798.issue12661@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Cleartree seems more equivalent to a shell expression, as you pointed out to find and -delete,than a utility. We might find those useful when work on CLI as opposed to programmatically needing them via APIs. (Won't you agree?) Chin, can you suggest certain use cases while writing programs that you would need to use cleartree api? While I like that function, I am  not sure if shutil should need that.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12661>
_______________________________________

From report at bugs.python.org  Sun Jul 31 03:36:42 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 31 Jul 2011 01:36:42 +0000
Subject: [issue12661] Add a new shutil.cleartree function to shutil module
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312076202.0.0.641757634227.issue12661@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
title: [new function] shutil.cleartree -> Add a new shutil.cleartree function to shutil module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12661>
_______________________________________

From report at bugs.python.org  Sun Jul 31 04:39:08 2011
From: report at bugs.python.org (Roman Evstifeev)
Date: Sun, 31 Jul 2011 02:39:08 +0000
Subject: [issue3177] Add shutil.open
In-Reply-To: <1214221105.24.0.576717506983.issue3177@psf.upfronthosting.co.za>
Message-ID: <1312079948.33.0.259110443183.issue3177@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3177>
_______________________________________

From report at bugs.python.org  Sun Jul 31 04:39:52 2011
From: report at bugs.python.org (Roman Evstifeev)
Date: Sun, 31 Jul 2011 02:39:52 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
	path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1312079992.18.0.348263362574.issue10395@psf.upfronthosting.co.za>


Changes by Roman Evstifeev <someuniquename at gmail.com>:


----------
nosy: +Roman.Evstifeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Sun Jul 31 04:59:17 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 31 Jul 2011 02:59:17 +0000
Subject: [issue12436] Provide reference to detailed installation instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1312081157.29.0.320140598311.issue12436@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I propose we close this, because it adds a little value as a separate bug. If there are specific sections in the docs that can be improved, we can deal with that.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12436>
_______________________________________

From report at bugs.python.org  Sun Jul 31 05:34:12 2011
From: report at bugs.python.org (Catherine Devlin)
Date: Sun, 31 Jul 2011 03:34:12 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312083252.17.0.203730518138.issue10087@psf.upfronthosting.co.za>


Catherine Devlin <fredv8vibwc at liquidid.net> added the comment:

Very simplistic patch to test_calendar.py that adds a test for this fix.  This fails on the unpatched trunk b/c the unpatched output begins with b"b'<?xm" instead of b"<?xml ".  Test needs a quick review... I'm not familiar with the conventions yet!

----------
nosy: +catherine
Added file: http://bugs.python.org/file22806/test_calendar_byteoutput.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Sun Jul 31 08:00:27 2011
From: report at bugs.python.org (Leonid Vasilev)
Date: Sun, 31 Jul 2011 06:00:27 +0000
Subject: [issue12661] Add a new shutil.cleartree function to shutil module
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312092027.18.0.24943167913.issue12661@psf.upfronthosting.co.za>


Leonid Vasilev <vsleonid at gmail.com> added the comment:

Added file with sample usage (extracted from real application).

the main purpose of shutil.cleartree()
is to remove unnecessary files from tree, where
patterns of ignored or deleted files are computed
dynamically.

Yes I agree, that it might be done by shell expression, but in case of dynamic patterns it will be hacky.

----------
Added file: http://bugs.python.org/file22807/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12661>
_______________________________________

From report at bugs.python.org  Sun Jul 31 09:38:13 2011
From: report at bugs.python.org (kota)
Date: Sun, 31 Jul 2011 07:38:13 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312097893.64.0.307964731675.issue12648@psf.upfronthosting.co.za>


kota <nospam.kotarou.dono at gmail.com> added the comment:

Yea, it runs the parser.py that time. And I didn't understand the page you linked me to. Would you mind explaining it a bit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12648>
_______________________________________

From report at bugs.python.org  Sun Jul 31 10:20:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Jul 2011 08:20:33 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312100433.29.0.462964389752.issue12648@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The Windows build actually uses the registry to locate the standard library rather than sys.path. This is by design, but isn't really documented properly.

It means that code on sys.path (even in the current directory) won't shadow standard library modules on Windows.

Due to various arcane details about how it is implemented, the emulation of the main import system that is used to run code with the '-m' switch gets the search order the other way around and hence gives a different answer (the same answer as Linux) in cases like this.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12648>
_______________________________________

From report at bugs.python.org  Sun Jul 31 12:37:57 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 31 Jul 2011 10:37:57 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312108677.81.0.310720530252.issue12646@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Looking at Lib/test/test_zlib.py, it appears that this behaviour is intentional
(see issue8672). I agree that having flush() raise an exception is the Right
Thing, but breaking existing code (which we know depends on this behavior) is
clearly a bad idea. @pitrou - anything thoughts on this?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12646>
_______________________________________

From report at bugs.python.org  Sun Jul 31 15:06:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Jul 2011 13:06:29 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <E1QnViu-0006f3-2s@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d98b5e0f0862 by Nadeem Vawda in branch 'default':
Fix build error in _curses module when not using libncursesw.
http://hg.python.org/cpython/rev/d98b5e0f0862

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Sun Jul 31 15:09:12 2011
From: report at bugs.python.org (ojab)
Date: Sun, 31 Jul 2011 13:09:12 +0000
Subject: [issue12662] Allow configparser to process suplicate options
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>


New submission from ojab <ojab at ojab.ru>:

Allow configparser to process duplicate options, just concatenating it's values, so using file

[sect1]
opt1=asd;
opt2=qwe
opt1=fgs

we will have config['sect1']['opt1'] == 'asd;fgs'

----------
components: Library (Lib)
messages: 141463
nosy: ojab
priority: normal
severity: normal
status: open
title: Allow configparser to process suplicate options
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12662>
_______________________________________

From report at bugs.python.org  Sun Jul 31 15:13:17 2011
From: report at bugs.python.org (kota)
Date: Sun, 31 Jul 2011 13:13:17 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312117997.16.0.450256248403.issue12648@psf.upfronthosting.co.za>


kota <nospam.kotarou.dono at gmail.com> added the comment:

So there isn't any way to load parser.py via import parser on Windows?

----------
components: +None -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12648>
_______________________________________

From report at bugs.python.org  Sun Jul 31 15:17:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 Jul 2011 13:17:59 +0000
Subject: [issue12662] Allow configparser to process suplicate options
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312118279.34.0.976358261076.issue12662@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/issue12662>
_______________________________________

From report at bugs.python.org  Sun Jul 31 15:18:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 31 Jul 2011 13:18:36 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1312118316.03.0.727454711121.issue12567@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Following d98b5e0f0862, I have been able to successfully build the curses
module with curses_unicode.patch applied.

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Sun Jul 31 15:19:29 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 31 Jul 2011 13:19:29 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1312118369.35.0.366884111237.issue12567@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Ack sorry, forgot to give context - my machine doesn't have libncursesw,
so the curses module failed to build before that commit (with or without
the patch applied).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Sun Jul 31 15:56:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 Jul 2011 13:56:43 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312120603.41.0.476414650438.issue10087@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/issue10087>
_______________________________________

From report at bugs.python.org  Sun Jul 31 16:33:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 14:33:57 +0000
Subject: [issue12663] ArgumentParser.error writes to stderr not to stdout
In-Reply-To: <1312122837.61.0.0244813637126.issue12663@psf.upfronthosting.co.za>
Message-ID: <1312122837.61.0.0244813637126.issue12663@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005210.html , here's a patch to fix it. It applies to all the relevant branches.

----------
assignee: docs at python
components: Documentation
files: ArgumentParser.error_stderr-default.patch
keywords: patch
messages: 141467
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: ArgumentParser.error writes to stderr not to stdout
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22808/ArgumentParser.error_stderr-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12663>
_______________________________________

From report at bugs.python.org  Sun Jul 31 16:59:09 2011
From: report at bugs.python.org (Aaron Robson)
Date: Sun, 31 Jul 2011 14:59:09 +0000
Subject: [issue12664] Path variable - Windows installer
In-Reply-To: <1312124349.72.0.418795016594.issue12664@psf.upfronthosting.co.za>
Message-ID: <1312124349.72.0.418795016594.issue12664@psf.upfronthosting.co.za>


New submission from Aaron Robson <shiny.magnum at googlemail.com>:

One of the main barriers to getting a working development environment for me was having to discover that I needed, learn about and find out how to set up the Path variable in Windows.

I propose an option in the installer (perhaps even set to be on by default) to allow the user to choose if they want it to be added to the list or not.

My apologies if this has been raised before (my searches in the tracker didn't turn up any similar problems), I am quite new to the issue tracker however.

----------
components: Installation
messages: 141468
nosy: AaronR
priority: normal
severity: normal
status: open
title: Path variable - Windows installer
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12664>
_______________________________________

From report at bugs.python.org  Sun Jul 31 17:08:32 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 15:08:32 +0000
Subject: [issue12665] Dictionary view example has error in set ops
In-Reply-To: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>
Message-ID: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005209.html here's a patch to fix the example error on active 3.x branches.

----------
assignee: docs at python
components: Documentation
files: dict_view_examples-default.patch
keywords: patch
messages: 141469
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Dictionary view example has error in set ops
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22809/dict_view_examples-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12665>
_______________________________________

From report at bugs.python.org  Sun Jul 31 17:16:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 Jul 2011 15:16:52 +0000
Subject: [issue12664] Path variable - Windows installer
In-Reply-To: <1312124349.72.0.418795016594.issue12664@psf.upfronthosting.co.za>
Message-ID: <1312125412.25.0.748353791361.issue12664@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Windows installer should add Python and Scripts directories to the PATH environment variable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12664>
_______________________________________

From report at bugs.python.org  Sun Jul 31 17:28:14 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 31 Jul 2011 15:28:14 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In `whatsnew/3.0.html`, there is little said about the map builtin:

map() and filter() return iterators. If you really need a list, a quick fix is e.g. list(map(...)), but a better fix is often to use a list comprehension (especially when the original code uses lambda), or rewriting the code so it doesn?t need a list at all. Particularly tricky is map() invoked for the side effects of the function; the correct transformation is to use a regular for loop (since creating a list would just be wasteful).

This suggests that all one must do to port to Python 3 is wrap map in list, and in fact this is what the 2to3 fixers do, when in fact, map is semantically different in how it handles arguments of different lengths. Consider the following.

    def to_tuple(*args):
        return args

    print(list(map(to_tuple, [1,2,3], [4,5,6,7])))

On Python 2, this code outputs:

[(1, 4), (2, 5), (3, 6), (None, 7)]

On Python 3, this code outputs:

[(1, 4), (2, 5), (3, 6)]

I suggest three fixes (in order of importance):

1) Document the difference in whatsnew/3.0.html.
2) Describe how one should port code of this usage to 3.0.
3) Incorporate the porting in the 2to3 fixer (if possible).

If no one objects, I'll begin on (1). Does anyone have any suggestions for a clean approach to (2)?

----------
assignee: docs at python
components: 2to3 (2.x to 3.0 conversion tool), Documentation
keywords: easy
messages: 141470
nosy: docs at python, jason.coombs
priority: normal
severity: normal
status: open
title: map semantic change not documented in What's New
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12666>
_______________________________________

From report at bugs.python.org  Sun Jul 31 18:02:30 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 31 Jul 2011 16:02:30 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312128150.45.0.556046543619.issue12666@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I believe the correct solution to (2) is to use itertools.zip_longest. So to port to Python 3, the example would use:

    print(list(map(to_tuple, itertools.zip_longest([1,2,3], [4,5,6,7]))))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12666>
_______________________________________

From report at bugs.python.org  Sun Jul 31 19:58:09 2011
From: report at bugs.python.org (phep)
Date: Sun, 31 Jul 2011 17:58:09 +0000
Subject: [issue9968] cgi.FieldStorage: Give control about the directory used
	for uploads
In-Reply-To: <1312033520.91.0.700156512253.issue9968@psf.upfronthosting.co.za>
Message-ID: <4E3597A9.4010104@teletopie.net>


phep <patrice.pillot at teletopie.net> added the comment:

Le 30/07/2011 15:45, ?ric Araujo a ?crit :
>
> ?ric Araujo<merwok at netwok.org>  added the comment:
> I?ve read in the tempfile module docstring that in order to control the
> directory, you have to set tempfile.tempdir before calling any tempfile
> function.  I suspect this will not be okay for some applications.  I
> wonder if the same limitation applies when one sets os.environ['TMP'].

You were right in pointing into this direction I forgot to mention in the 
doc part of the patch. I've had a look at tempfile implementation and made 
some tests and this led me to notice a documentation problem that might be 
worth considering (cf. infra).

But first things first: Actually, after reading tempfile.py, I cannot see 
the reason of the tempfile docstring about tempdir, except maybe for 
performance reasons. Setting tempfile.tempdir manually should not be a 
problem in any case: direct access to the member or call to 
tempfile.gettempdir() - except maybe in the very improbable case where 
tempdir would first be set to some not None value then re-set to None and a 
nasty trick I overlooked is lurking inside of the gettempdir() 
concurrent-access lock...

But, on the other hand, trying to tweak the system by using os.environ on 
TMP and such may well fail in a number of occasions since those variables 
won't be checked after the first call to tempfile.gettempdir() (except if 
tempfile.tempdir is reset to None). I wonder if the file docstring does not 
relate to this problem, as a matter of fact.

> In the light of that, do you think the tempfile solution is enough, or do
> you want to get back to the earlier idea of adding an argument to
> FieldStorage?

I can't think it of any reasonable use case that would make necessary to 
overload the interface right now provided the need to (maybe) set 
tempfile.tempdir is documented.

At last, as a side note, during the tests I ran, I noticed one should really 
not use os.rename() since this raises an OSError (file not found) upon 
script termination (since the NamedTemporaryFile has been ... renamed, hey).

As this problem does not concern the present issue, I did not deemed 
necessary to edit the documentation accordingly. Yet this might be debatable 
since the doc never explicitly says FieldStorage uses a (Named)TemporaryFile 
under the hood. Do you think one should state explicitly the coupling of 
those modules ?

> (One advantage of doc changes is that they can get committed to 2.7, 3.2
> and 3.3 and get published immediately.  We can anyway make a code change
> in 3.3 and a doc change for older versions.)

On this topic, I was wondering if the changes I propose have any chance of 
landing some day in 2.7 land - dunno Python workflow precisely enough.

>> I fiddled last night with setting an environment to deploy and test a
>> patched Python
> Are you aware of the developers? guide?
> http://docs.python.org/devguide/

Yep, it helped me. It just took me some time to be sure to get it right, run 
the tests, ... (by the way, patchcheck.py seems to be broken).

>> (I had some problem to understand what happened when I encountered
>> 6755).
> What is 6755?

Sorry, I meant issue 6755.

> ---------- title: Let cgi.FieldStorage have named uploaded file ->
> cgi.FieldStorage: Give control about the directory used for uploads

Well, actually, the useful feature in the patch is the possibility to have a 
named-hence-linkable uploaded file. Giving control on the upload directory 
is but a useful-while-quite-necessary sister-feature, isn't it ?

>
> _______________________________________ Python
> tracker<report at bugs.python.org> <http://bugs.python.org/issue9968>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9968>
_______________________________________

From report at bugs.python.org  Sun Jul 31 20:01:18 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 18:01:18 +0000
Subject: [issue12667] Better logging.handler.SMTPHandler doc for 'secure'
	argument
In-Reply-To: <1312135278.74.0.984312174238.issue12667@psf.upfronthosting.co.za>
Message-ID: <1312135278.74.0.984312174238.issue12667@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005207.html here are 2 patches to correct the documentation for 'secure' argument of SMTPHandler:

- the one for default (applicable also on 3.2) adds completely the 'secure' arg (missing)
- the one for 2.7 corrects the wrong information.

Both are taken from the docstring, that seems perfectly usable for the doc.

----------
assignee: docs at python
components: Documentation
files: logging_smtphandler_secure-default.patch
keywords: patch
messages: 141473
nosy: docs at python, sandro.tosi, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Better logging.handler.SMTPHandler doc for 'secure' argument
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22810/logging_smtphandler_secure-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12667>
_______________________________________

From report at bugs.python.org  Sun Jul 31 20:01:26 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 18:01:26 +0000
Subject: [issue12667] Better logging.handler.SMTPHandler doc for 'secure'
	argument
In-Reply-To: <1312135278.74.0.984312174238.issue12667@psf.upfronthosting.co.za>
Message-ID: <1312135286.87.0.92175555332.issue12667@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file22811/logging_smtphandler_secure-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12667>
_______________________________________

From report at bugs.python.org  Sun Jul 31 20:08:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 31 Jul 2011 18:08:33 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1312040280.03.0.299305836969.issue12183@psf.upfronthosting.co.za>
Message-ID: <20110731180829.GB2219@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

Senthil Kumaran wrote:
> When shutil.copy2 already says that it's behavior is equivalent to cp -p, will adding this sentence
> 
> +   Symbolic links are not preserved. The contents and metadata of the
> +   linked files are copied instead.
> 
> Not actively confuse the user? Because cp -p's behavior includes
> that and I dont see a special mention without giving more details is
> going to help.

You're right. Only copytree() seems to understand symlinks, so
deferencing symlinks is the "default" mode of operation.

I updated the patch to remove the first hunk.

----------
Added file: http://bugs.python.org/file22812/copy2_copytree_symlinks_2.7_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12183>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst
index 1b160d8..99ee111 100644
--- a/Doc/library/shutil.rst
+++ b/Doc/library/shutil.rst
@@ -105,8 +108,9 @@ Directory and files operations
    :func:`copy2`.
 
    If *symlinks* is true, symbolic links in the source tree are represented as
-   symbolic links in the new tree; if false or omitted, the contents of the
-   linked files are copied to the new tree.
+   symbolic links in the new tree, but the metadata of the original links is NOT
+   copied; if false or omitted, the contents and metadata of the linked files
+   are copied to the new tree.
 
    If *ignore* is given, it must be a callable that will receive as its
    arguments the directory being visited by :func:`copytree`, and a list of its

From report at bugs.python.org  Sun Jul 31 20:23:01 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 31 Jul 2011 18:23:01 +0000
Subject: [issue12626] run test cases based on a glob filter
In-Reply-To: <1311457686.18.0.680681254529.issue12626@psf.upfronthosting.co.za>
Message-ID: <1312136581.95.0.272427017866.issue12626@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I agree with Antoine, as test.support is not a public api adding new features to assist with debugging is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12626>
_______________________________________

From report at bugs.python.org  Sun Jul 31 23:19:40 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 21:19:40 +0000
Subject: [issue12668] 3.2 What's New: it's integer->string, not the opposite
In-Reply-To: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>
Message-ID: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005087.html, here's a patch to fix the 3.2 What's New section.

----------
assignee: docs at python
components: Documentation
files: whatsnew_3.2_int2str-default.patch
keywords: patch
messages: 141476
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: 3.2 What's New: it's integer->string, not the opposite
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22813/whatsnew_3.2_int2str-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12668>
_______________________________________

From report at bugs.python.org  Sun Jul 31 23:31:22 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 31 Jul 2011 21:31:22 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1312147882.94.0.485223995043.issue12641@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sun Jul 31 23:52:15 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 31 Jul 2011 21:52:15 +0000
Subject: [issue12669] test_curses skipped on buildbots
In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>
Message-ID: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

When running regrtest with the -j and/or -w options, test_curses gets skipped,
complaining that stdout is not a tty. This means that the buildbots never run
this test, which is obviously a Bad Thing.

For the -w case (which applies to the buildbots), this is caused by sys.stdout
(and sys.stderr) being replaced with a StringIO instance. We can work around
this in the test by using sys.__stdout__ instead. This is perhaps ugly, but it
seems to work, and is much better than doing nothing. For the record, this has
already been proposed in issue7096 (now dead).

For the -j case things aren't quite so straightforward - each test is run in a
subprocess, with stdout and stderr redirected to pipes, so there isn't an easy
way to access the terminal the process is associated with. Off the top of my
head, the only way I can think of to work around this is to special-case
test_curses so that it runs in the main process, and I'd really much rather not
do that. Thankfully this case doesn't apply to the buildbots at present, but it
is still bothersome when running tests locally.

TLDR:
1. Is there any reason for test_curses not to use sys.__stdout__?
2. Any ideas on how to get test_curses working with regrtest.py -j?

----------
components: Tests
messages: 141477
nosy: ezio.melotti, haypo, michael.foord, nadeem.vawda, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: test_curses skipped on buildbots
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12669>
_______________________________________