From report at bugs.python.org  Sun May  1 00:15:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Apr 2011 22:15:10 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304201710.96.0.0426989644523.issue11935@psf.upfronthosting.co.za>


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

The problem with this patch is that it would also show 'new mail' if what had in fact happened was that a message had been *deleted* (see the comments at the beginning of the flush method).  So actually fixing this is a bit more complicated.

A proper fix for this should also consider fixing issue 7359.

----------

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

From report at bugs.python.org  Sun May  1 00:17:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Apr 2011 22:17:41 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1304201861.85.0.309399168609.issue11964@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/issue11964>
_______________________________________

From report at bugs.python.org  Sun May  1 00:17:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Apr 2011 22:17:51 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1304201871.35.0.419142057525.issue11882@psf.upfronthosting.co.za>


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

Kasun, were you able to reproduce the problem (or show it doesn't happen) calling mktime directly from C?

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

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

From report at bugs.python.org  Sun May  1 01:15:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 23:15:44 +0000
Subject: [issue11962] FreeBSD-AMD64 bot sporadic hanging
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304205344.9.0.930642691804.issue11962@psf.upfronthosting.co.za>


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

> The FreeBSD-AMD64 bot exhibits sporadic hanging in unspecific places.

You can try a shorter regrtest timeout, edit Lib/test/regrtest.py near:

    if hasattr(faulthandler, 'dump_tracebacks_later'):
        timeout = 60*60

(or use --timeout option of the regrtest.py program)

If you have an access to a terminal (using ssh), you can also set a signal to dump the traceback: edit regrtest.py to add "import signal; faulthandler.register(signal.SIGUSR1, all_threads=True)" after "faulthandler.enable()". Then use "kill -USR1 pid" to dump the traceback.

Or the problem is an unlimited loop while dumping the traceback because of a timeout :-D In this case, disable the timeout using --timeout=0 option of regrtest.py.

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

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

From report at bugs.python.org  Sun May  1 01:17:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 23:17:46 +0000
Subject: [issue11361] suggestion for os.kill(pid,CTRL_C_EVENT) in tests
In-Reply-To: <1298986221.06.0.20392871991.issue11361@psf.upfronthosting.co.za>
Message-ID: <1304205466.36.0.000876920971666.issue11361@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/issue11361>
_______________________________________

From report at bugs.python.org  Sun May  1 01:23:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Apr 2011 23:23:07 +0000
Subject: [issue11958] test.test_ftplib.TestIPv6Environment failure
In-Reply-To: <1304111281.72.0.014569295805.issue11958@psf.upfronthosting.co.za>
Message-ID: <E1QGJVC-00024v-3z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e680564efa8c by Victor Stinner in branch 'default':
Close #11958: Fix FTP tests for IPv6, bind to "::1" instead of "localhost".
http://hg.python.org/cpython/rev/e680564efa8c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun May  1 01:24:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 23:24:29 +0000
Subject: [issue11958] test.test_ftplib.TestIPv6Environment failure
In-Reply-To: <1304111281.72.0.014569295805.issue11958@psf.upfronthosting.co.za>
Message-ID: <1304205869.79.0.634127112857.issue11958@psf.upfronthosting.co.za>


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

We may have a support.HOST_IPV6 constant, but I would imply to modify many tests to use it. I prefer to apply your simple patch, thanks!

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

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

From report at bugs.python.org  Sun May  1 01:40:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Apr 2011 23:40:13 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304206813.16.0.52372723793.issue11887@psf.upfronthosting.co.za>


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

unittest_str_bytes-2.patch:
 - add new tests to reproduce the bug
 - fix the bug: ignore temporary BytesWarning warnings while comparing objects and sequences

----------
Added file: http://bugs.python.org/file21844/unittest_str_bytes-2.patch

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

From report at bugs.python.org  Sun May  1 01:43:37 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 30 Apr 2011 23:43:37 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304207017.82.0.684890313364.issue10419@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Apparently setuptools.command.easy_install.get_script_header() imports distutils.command.build_scripts.first_line_re and checks if this regex matches a str object, which results in TypeError. If breaking compatibility is not acceptable, then the surrogateescape patch should be applied.

----------

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

From report at bugs.python.org  Sun May  1 01:49:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Apr 2011 23:49:08 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304207348.56.0.739452461877.issue11873@psf.upfronthosting.co.za>


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

The failing test is launching a subprocess to compile python code, waiting for the subprocess to exit, and then checking to see if the file was created.  So the timing issue would appear to be that the file created by the subprocess doesn't appear to exist to the main program even after the subprocess has exited.  Stefan, Jesus, do either of you know of anything about the file systems used on your buildbots that might give rise to this problem?  Is there some sort of file system sync call we need to make to make sure different processes have the same view of the file system?

However, if my theory is true I would expect that other tests in test_compileall would also fail randomly.  Does anyone know if it is always test_regexp?

----------
nosy: +jcea, skrah

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

From report at bugs.python.org  Sun May  1 05:01:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 01 May 2011 03:01:53 +0000
Subject: [issue11963] Use real assert* for test_trigger_memory_error
	(test_parser)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1304218913.93.0.360543492433.issue11963@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think the patch is OK.
FWIW I tried to replace sys.stderr with a StringIO to see if it was possible to keep using assertRaises and then read the value from the StringIO but that didn't work.

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

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

From report at bugs.python.org  Sun May  1 05:05:23 2011
From: report at bugs.python.org (David Albert Torpey)
Date: Sun, 01 May 2011 03:05:23 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>


New submission from David Albert Torpey <dtorp at users.sourceforge.net>:

I would like to left and right shift floats as a fast way to multiply or divide by a power of 2 without rounding error.  The only way to do that now is t=frexp(x) and y=ldexp(t[0],t[1]+2).  But would be better to type y=x<<2.  Thank you.

----------
messages: 134897
nosy: dtorp
priority: normal
severity: normal
status: open
title: Left shift and Right shift for floats
versions: Python 3.3

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

From report at bugs.python.org  Sun May  1 05:09:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 01 May 2011 03:09:23 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304219363.41.0.95695599703.issue11967@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun May  1 05:19:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 03:19:06 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1304219946.47.0.669498844237.issue9756@psf.upfronthosting.co.za>


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

The test suite crashs randomly with issue9756.patch on my Ubuntu 11.04 (AMD64 with 4 cores, 4 GB of memory, Linux 2.6.38). I use "./python -bb Lib/test/regrtest.py -r" to reproduce the crash.

... I tried without the patch, and test_descr does crash quickly in test_wrapper_segfault(). It crashs in _PyObject_GC_New(), in a callback used to release the memory. Sometimes it fails on update_refs(), sometimes in _PyObject_DebugFree(), sometimes in wrapper_dealloc()->_Py_ForgetReference, etc. I use "./python Lib/test/regrtest.py -F -v test_descr" to reproduce the crash (sometimes it takes more than one run to crash).

It's strange because I'm unable to reproduce the bug on a very similar setup (Debian Sid, AMD64 with 2 cores, 2 GB of memory, Linux 2.6.38).

Should I run a memcheck on the Ubuntu host? Or is anyone able to reproduce the bug?

----------

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

From report at bugs.python.org  Sun May  1 05:27:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 May 2011 03:27:16 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304220436.73.0.512310756856.issue11967@psf.upfronthosting.co.za>


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


----------
components: +Interpreter Core
nosy: +rhettinger
type:  -> feature request

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

From report at bugs.python.org  Sun May  1 06:00:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 04:00:28 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1304222428.55.0.540366906891.issue9756@psf.upfronthosting.co.za>


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

Oh, the Ubuntu host has a temperature issue and hardware errors... Example of mcelog output:
--------------------------------
MCE 0
CPU 0 THERMAL EVENT TSC 198d1eb8325
TIME 1304222195 Sun May  1 05:56:35 2011
Processor 0 heated above trip temperature. Throttling enabled.
Please check your system cooling. Performance will be impacted
STATUS 8801000f MCGSTATUS 0
MCGCAP 806 APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 23
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
--------------------------------

----------

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

From report at bugs.python.org  Sun May  1 07:56:24 2011
From: report at bugs.python.org (Takayuki SHIMIZUKAWA)
Date: Sun, 01 May 2011 05:56:24 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>


New submission from Takayuki SHIMIZUKAWA <shimizukawa at gmail.com>:

WSGI sapmle code at wsgiref document (http://docs.python.org/py3k/library/wsgiref.html#wsgiref.util.setup_testing_defaults) was broken.


- status = b'200 OK'
- headers = [(b'Content-type', b'text/plain; charset=utf-8')]
+ status = '200 OK'
+ headers = [('Content-type', 'text/plain; charset=utf-8')]

----------
assignee: docs at python
components: Documentation
messages: 134900
nosy: docs at python, shimizukawa
priority: normal
severity: normal
status: open
title: wsgiref's wsgi application sample code does not work
versions: Python 3.2

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

From report at bugs.python.org  Sun May  1 08:03:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 May 2011 06:03:45 +0000
Subject: [issue11962] FreeBSD-AMD64 bot sporadic hanging
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304229825.7.0.347116278938.issue11962@psf.upfronthosting.co.za>


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

Thanks Victor, I can try some of that.

Could this also be a problem with the buildbot software or a networking
problem? The Ubuntu PPC bot might have the same issue. Here the tests
appear to be finished but the clean doesn't start:

http://www.python.org/dev/buildbot/all/builders/PPC%20Ubuntu%203.1/builds/387/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/PPC%20Ubuntu%203.1/builds/387

----------

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

From report at bugs.python.org  Sun May  1 09:24:05 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 01 May 2011 07:24:05 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304234645.77.0.00199247003177.issue11967@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/issue11967>
_______________________________________

From report at bugs.python.org  Sun May  1 10:39:07 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 May 2011 08:39:07 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1304207348.56.0.739452461877.issue11873@psf.upfronthosting.co.za>
Message-ID: <20110501083748.GA17697@sleipnir.bytereef.org>


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

R. David Murray <report at bugs.python.org> wrote:
> The failing test is launching a subprocess to compile python code, waiting
> for the subprocess to exit, and then checking to see if the file was
> created.  So the timing issue would appear to be that the file created by
> the subprocess doesn't appear to exist to the main program even after the
> subprocess has exited.  Stefan, Jesus, do either of you know of anything
> about the file systems used on your buildbots that might give rise to this
> problem?  Is there some sort of file system sync call we need to make to
> make sure different processes have the same view of the file system?

The FreeBSD bot has a UFS filesystem with no soft updates:

$ mount
/dev/ad0s1a on / (ufs, local)

If the main process waits for the subprocess to finish, I can't think of
a reason to do any kind of synchronization.

----------

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

From report at bugs.python.org  Sun May  1 10:50:05 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 01 May 2011 08:50:05 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304239805.6.0.58227535257.issue11967@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


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

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

From report at bugs.python.org  Sun May  1 11:11:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 May 2011 09:11:58 +0000
Subject: [issue11912] PaX triggers a segfault in dlopen
In-Reply-To: <1303601985.39.0.925824346967.issue11912@psf.upfronthosting.co.za>
Message-ID: <1304241118.85.0.00535271260775.issue11912@psf.upfronthosting.co.za>


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

> Is there any reason not to close this as a CPython issue? 

No, it's definitely not a CPython issue. I'm closing as invalid.

----------
resolution:  -> invalid
status: open -> closed
title: Python shouldn't use the mprotect() system call -> PaX triggers a segfault in dlopen

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

From report at bugs.python.org  Sun May  1 11:51:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 01 May 2011 09:51:29 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304243489.25.0.3426595204.issue11967@psf.upfronthosting.co.za>


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

"The only way ..." That's not true. y=x*(1<<n) is also an exact multiplication with a power of two, and it's also fairly fast. Likewise for y=x/(1<<n).

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

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

From report at bugs.python.org  Sun May  1 13:34:24 2011
From: report at bugs.python.org (Alexander Vrchoticky)
Date: Sun, 01 May 2011 11:34:24 +0000
Subject: [issue11270] logging: RotatingFileHandler crash when opening the
	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1304249664.13.0.341798109304.issue11270@psf.upfronthosting.co.za>


Alexander Vrchoticky <Alexander.Vrchoticky at gmx.at> added the comment:

I hit that problem too (Python 2.6.5). We have a Windows service application (daemon, in Unix parlance). This is written in Python and uses RotatingFileHandler to rotate files when they exceed 1MB. We look at the files for debugging. For a live view of log entries, we use less.exe in follow mode. 

If the rotating log handler hits the size limit while the current log file is watched, it throws an exception and logging is broken henceforth. Restarting the service while less.exe is still running does not help, it hits the same exception right from the outset.

Since we cannot stop users from looking at the log files, and we cannot have our service application die by user interaction, this is a serious problem.

I am confused by the statement that "you should not look at the files as long as they are under the library's control". As I understood, on rotating, the oldest file will be deleted, all others will be renamed, and a new file will be created. No file will remain untouched. As far as the human log reader is concerned, rotation can happen at any time, so all log files are under control of the library for their entire life.
If that's true, why bother writing them in the first place? :-)

The root problem is that RotatingFileHandler cannot rename the file while less.exe has it open. Under Unix-like file systems, this problem may not appear: Renaming an open file works, and the file descriptor held by less.exe remains valid. The logger is free to create another file with the same name. Under Windows, files and directory entries are more closely related. Hence, the error "The process cannot access the file because it is being used by another process". I do not know if it is possible to work around this.

Comments are appreciated. RotatingFileHandler looks like a good match for long-running service applications. If this issue remains unresolved, it is not. A word of warning in the docs seems appropriate in this case.

----------
nosy: +avrchoti

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

From report at bugs.python.org  Sun May  1 15:09:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 13:09:08 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1304219946.47.0.669498844237.issue9756@psf.upfronthosting.co.za>
Message-ID: <1304255345.30334.10.camel@marge>


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

Le dimanche 01 mai 2011 ? 03:19 +0000, STINNER Victor a ?crit :
> The test suite crashs randomly with issue9756.patch on my Ubuntu 11.04
> (AMD64 with 4 cores, 4 GB of memory, Linux 2.6.38). I use "./python
> -bb Lib/test/regrtest.py -r" to reproduce the crash.
> 
> ... I tried without the patch, and test_descr does crash quickly in
> test_wrapper_segfault(). It crashs in _PyObject_GC_New(), in a
> callback used to release the memory. Sometimes it fails on
> update_refs(), sometimes in _PyObject_DebugFree(), sometimes in
> wrapper_dealloc()->_Py_ForgetReference, etc. I use "./python
> Lib/test/regrtest.py -F -v test_descr" to reproduce the crash
> (sometimes it takes more than one run to crash).
> 
> It's strange because I'm unable to reproduce the bug on a very similar
> setup (Debian Sid, AMD64 with 2 cores, 2 GB of memory, Linux 2.6.38).
> 
> Should I run a memcheck on the Ubuntu host? Or is anyone able to
> reproduce the bug?

Ok, I'm sure that I have hardware issues, but I am also sure that the
patch introduces random crashes, especially in
test_descr.test_wrapper_segfault().

I tried to only patch methoddescr_call(): replace PyObject_IsInstance()
by _PyObject_RealIsSubclass() introduces the crash. Call
PyObject_IsInstance() after _PyObject_RealIsSubclass() doesn't help.
But... call PyObject_IsInstance() before _PyObject_RealIsSubclass()
avoids the crash !?

----------

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

From report at bugs.python.org  Sun May  1 15:25:56 2011
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 01 May 2011 13:25:56 +0000
Subject: [issue11969] Can't launch Process on built-in static method
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Hello,

I found this bit in my inbox, I forgot why I cared about it, but it raises an exception (at least on Windows):

>>> import multiprocessing
>>> p = multiprocessing.Process(target=bytes.maketrans, args=(b'abc', b'xyz'))
>>> p.start()
Traceback (most recent call last):
  File "C:\Python32\Lib\pickle.py", line 679, in save_global
    klass = getattr(mod, name)
AttributeError: 'module' object has no attribute 'maketrans'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python32\Lib\multiprocessing\process.py", line 130, in start
    self._popen = Popen(self)
  File "C:\Python32\Lib\multiprocessing\forking.py", line 267, in __init__
    dump(process_obj, to_child, HIGHEST_PROTOCOL)
  File "C:\Python32\Lib\multiprocessing\forking.py", line 190, in dump
    ForkingPickler(file, protocol).dump(obj)
  File "C:\Python32\Lib\pickle.py", line 237, in dump
    self.save(obj)
  File "C:\Python32\Lib\pickle.py", line 344, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python32\Lib\pickle.py", line 432, in save_reduce
    save(state)
  File "C:\Python32\Lib\pickle.py", line 299, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python32\Lib\pickle.py", line 623, in save_dict
    self._batch_setitems(obj.items())
  File "C:\Python32\Lib\pickle.py", line 656, in _batch_setitems
    save(v)
  File "C:\Python32\Lib\pickle.py", line 299, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python32\Lib\pickle.py", line 683, in save_global
    (obj, module, name))
_pickle.PicklingError: Can't pickle <built-in function maketrans>: it's not found as __main__.maketrans

If you do the same things with `threading.Thread`, it works, but for `multiprocessing.Process` it doesn't. Is this a general problem with pickling "unbound methods"?

----------
components: Interpreter Core, Library (Lib)
messages: 134907
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Can't launch Process on built-in static method
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun May  1 15:42:21 2011
From: report at bugs.python.org (Chris Rose)
Date: Sun, 01 May 2011 13:42:21 +0000
Subject: [issue11970] distutils command 'upload' crashes when --show-response
	is selected
In-Reply-To: <1304257341.36.0.351902747492.issue11970@psf.upfronthosting.co.za>
Message-ID: <1304257341.36.0.351902747492.issue11970@psf.upfronthosting.co.za>


New submission from Chris Rose <offby1 at offby1.net>:

When running distutils like so:

.tox/py27/bin/python setup.py -v bdist_egg upload --show-response 

Eventually, after everything else spools by, this pops up:


Using PyPI login from /Users/offline/.pypirc
Submitting dist/PyHamcrest-1.5-py2.7.egg to http://pypi.python.org/pypi
Upload failed (401): You must be identified to edit package information
Traceback (most recent call last):
  File "setup.py", line 69, in <module>
    setup(**all_params)
  File "/usr/local/Cellar/python/2.7.1/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/Cellar/python/2.7.1/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/Cellar/python/2.7.1/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/Cellar/python/2.7.1/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/Cellar/python/2.7.1/lib/python2.7/distutils/command/upload.py", line 193, in upload_file
    msg = '\n'.join(('-' * 75, r.read(), '-' * 75))
NameError: global name 'r' is not defined

----------
assignee: tarek
components: Distutils
files: upload-failed.log
messages: 134908
nosy: eric.araujo, offby1, tarek
priority: normal
severity: normal
status: open
title: distutils command 'upload' crashes when --show-response is selected
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file21845/upload-failed.log

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

From report at bugs.python.org  Sun May  1 15:51:36 2011
From: report at bugs.python.org (Lars Michelsen)
Date: Sun, 01 May 2011 13:51:36 +0000
Subject: [issue11971] Wrong parameter -O0 instead of -OO in manpage
In-Reply-To: <1304257896.02.0.842593796082.issue11971@psf.upfronthosting.co.za>
Message-ID: <1304257896.02.0.842593796082.issue11971@psf.upfronthosting.co.za>


New submission from Lars Michelsen <lm at larsmichelsen.com>:

Hello Devs,

digging around in the python manpage and playing with the parameters I found a wrong parameter specification in the python manpage. The -OO parameter for discarding docstrings is written as -O0 (the 2nd is a zero).

A patch is attached.

Regards

----------
assignee: docs at python
components: Documentation
files: fix-OO-param.patch
keywords: patch
messages: 134909
nosy: docs at python, lm
priority: normal
severity: normal
status: open
title: Wrong parameter -O0 instead of -OO in manpage
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21846/fix-OO-param.patch

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

From report at bugs.python.org  Sun May  1 16:01:00 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 01 May 2011 14:01:00 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304258460.65.0.817149125427.issue11959@psf.upfronthosting.co.za>


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

I've made a patch. See

https://bitbucket.org/vinay.sajip/cpython-smtpd/compare/default..mirror/cpython

----------

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

From report at bugs.python.org  Sun May  1 16:58:33 2011
From: report at bugs.python.org (Michal Molhanec)
Date: Sun, 01 May 2011 14:58:33 +0000
Subject: [issue11972] input does not strip a trailing newline correctly on
	Windows
In-Reply-To: <1304261913.63.0.142734061698.issue11972@psf.upfronthosting.co.za>
Message-ID: <1304261913.63.0.142734061698.issue11972@psf.upfronthosting.co.za>


New submission from Michal Molhanec <molhanec at gmail.com>:

input() returns string including trailing '\r'. IMHO the problem is not directly in the input() function which just expects that the input string was read in text mode so all of the platform specific newlines were normalized into single '\n'.

----------
components: IO, Library (Lib), Windows
messages: 134911
nosy: Michal.Molhanec
priority: normal
severity: normal
status: open
title: input does not strip a trailing newline correctly on Windows
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun May  1 17:00:31 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 01 May 2011 15:00:31 +0000
Subject: [issue11972] input does not strip a trailing newline correctly on
	Windows
In-Reply-To: <1304261913.63.0.142734061698.issue11972@psf.upfronthosting.co.za>
Message-ID: <1304262031.54.0.219470233296.issue11972@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

See issue #11272.

----------
nosy: +Trundle

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

From report at bugs.python.org  Sun May  1 17:00:47 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 01 May 2011 15:00:47 +0000
Subject: [issue11972] input does not strip a trailing newline correctly on
	Windows
In-Reply-To: <1304261913.63.0.142734061698.issue11972@psf.upfronthosting.co.za>
Message-ID: <1304262047.39.0.81008038235.issue11972@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Duplicate of #11642, #11272, and #11278.

This is fixed. It'll be released in 3.2.1

----------
nosy: +brian.curtin
resolution:  -> duplicate
stage:  -> committed/rejected

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

From report at bugs.python.org  Sun May  1 17:15:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2011 15:15:26 +0000
Subject: [issue11971] Wrong parameter -O0 instead of -OO in manpage
In-Reply-To: <1304257896.02.0.842593796082.issue11971@psf.upfronthosting.co.za>
Message-ID: <E1QGYMm-0004NT-Lg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d70b0137902b by R David Murray in branch '2.7':
#11971: fix man page; it's -OO not -O0
http://hg.python.org/cpython/rev/d70b0137902b

New changeset c57fdce01eb8 by R David Murray in branch '3.1':
#11971: fix man page; it's -OO not -O0
http://hg.python.org/cpython/rev/c57fdce01eb8

New changeset bbc6129f7861 by R David Murray in branch '3.2':
Merge #11971: fix man page; it's -OO not -O0
http://hg.python.org/cpython/rev/bbc6129f7861

New changeset e2f71bc9b0db by R David Murray in branch 'default':
Merge #11971: fix man page; it's -OO not -O0
http://hg.python.org/cpython/rev/e2f71bc9b0db

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

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

From report at bugs.python.org  Sun May  1 17:16:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 May 2011 15:16:25 +0000
Subject: [issue11971] Wrong parameter -O0 instead of -OO in manpage
In-Reply-To: <1304257896.02.0.842593796082.issue11971@psf.upfronthosting.co.za>
Message-ID: <1304262985.36.0.220992346581.issue11971@psf.upfronthosting.co.za>


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

Thanks for catching that, and for the patch.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun May  1 19:25:30 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 01 May 2011 17:25:30 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304270730.14.0.673450151431.issue11967@psf.upfronthosting.co.za>


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

Would you want x >> 2 to be equivalent to x / 4.0 or x // 4.0?

----------

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

From report at bugs.python.org  Sun May  1 19:50:54 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 01 May 2011 17:50:54 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304272254.43.0.149286889953.issue11967@psf.upfronthosting.co.za>


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

> The only way to do that now is t=frexp(x) and y=ldexp(t[0],t[1]+2).

What's wrong with the more direct ldexp(x, 2)?

N.B.  There *are* edge cases where Martin's suggested alternative won't work.  E.g., to compute 1e-300 * 2**1500:

>>> ldexp(1e-300, 1500)
3.507466211043404e+151

But:

>>> 1e-300 * (1 << 1500)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

I'm -1 on the proposal:  I recognise the need for these operations, but I think 'ldexp(x, n)' gives an adequate solution.  Fitting the functionality to the << and >> operators is awkward, because that's not what those operators do for integers (>> produces the *floor* of the quotient, and << doesn't currently accept negative arguments on the right, so there's no neat way for integers to divide by a power of 2).

See also the rejected issue 1205239.

----------

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

From report at bugs.python.org  Sun May  1 20:26:34 2011
From: report at bugs.python.org (David Naylor)
Date: Sun, 01 May 2011 18:26:34 +0000
Subject: [issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)
In-Reply-To: <1304274394.46.0.0260368215252.issue11973@psf.upfronthosting.co.za>
Message-ID: <1304274394.46.0.0260368215252.issue11973@psf.upfronthosting.co.za>


New submission from David Naylor <naylor.b.david at gmail.com>:

kevent does not accept all legitimate parameters, such as KQ_NOTE_EXIT.  

For example:
>> from select import *
>> kevent(0, KQ_FILTER_PROC, KQ_EV_ADD | KQ_EV_ENABLE, KQ_NOTE_EXIT)
OverflowError: signed integer is greater than maximum

While the following C code compiles (under -Wall -pedantic) without error, or warning:
"""
#include <sys/types.h>
#include <sys/event.h>
#include <sys/time.h>

int main(int argc, char **argv) {

  struct kevent ke;

  EV_SET(&ke, 0, EVFILT_PROC, EV_ADD | EV_ENABLE, NOTE_EXIT, 0, 0);

  return (0);

}
"""

Looking at the Modules/selectmodule.c file it is clear that the fields "flags" and "fflags" are defined as T_USHORT and T_UINT however the flags passed to PyArg_ParseTupleAndKeywords are 'h' and 'i' respectively (implying signed numbers).  

A workaround exists where values X > (2**31 - 1) are passed as (X - 2**32).  Also the attached patch fixes the error.

----------
components: Extension Modules
files: patch-Modules-selectmodule.c
messages: 134918
nosy: DragonSA
priority: normal
severity: normal
status: open
title: kevent does not accept KQ_NOTE_EXIT (and other (f)flags)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21847/patch-Modules-selectmodule.c

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

From report at bugs.python.org  Sun May  1 20:34:49 2011
From: report at bugs.python.org (Cal Leeming)
Date: Sun, 01 May 2011 18:34:49 +0000
Subject: [issue11974] Class definition gotcha.. should this be documented
	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>


New submission from Cal Leeming <cal.leeming at simplicitymedialtd.co.uk>:

So, when you create a class like this:

class Obj:
    children = []

The 'children' object essentially becomes shared across all instances of Obj. To get around this, you have to use:

class Obj:
    children = None
    def __init__(self):
        children = []

I have attached proof of concept code which can trigger this bug. Although I have almost 8 years of experience with Python, this is the first time I have actually noticed this, however, I am sure that similar things have happened in the past, and I just didn't investigate it enough to realise what was going on.

Although this isn't a bug, it is likely that other advanced developers may also not know about, or have been caught out by this little gotcha. So, perhaps it might be worth documenting it somewhere?

Let me know your thoughts.

Cal

----------
components: Interpreter Core
files: obj.py
messages: 134919
nosy: sleepycal
priority: normal
severity: normal
status: open
title: Class definition gotcha.. should this be documented somewhere?
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file21848/obj.py

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

From report at bugs.python.org  Sun May  1 20:50:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 May 2011 18:50:22 +0000
Subject: [issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)
In-Reply-To: <1304274394.46.0.0260368215252.issue11973@psf.upfronthosting.co.za>
Message-ID: <1304275822.46.0.561091709588.issue11973@psf.upfronthosting.co.za>


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


----------
nosy: +ned.deily, ronaldoussoren
stage:  -> patch review
versions:  -Python 2.5, Python 2.6, Python 3.4

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

From report at bugs.python.org  Sun May  1 21:19:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 May 2011 19:19:21 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1304277561.65.0.17265754531.issue11943@psf.upfronthosting.co.za>


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

Thanks for the patch. Some preliminary comments:

- the OpenSSL functions you are using (SSL_get_srp_username etc.) don't seem documented on openssl.org; this makes it harder to do a proper review
- no need to fill Misc/ACKS and Misc/NEWS by yourself, we can take care of that
- what is an "SRP vbase"? is it something standardized, or OpenSSL-specific?
- if server-side support needs a callback, I think it would be better to let users write their callback in Python, rather than force a hardwired implementation
- ssl.wrap_socket() is the legacy API, I would rather add new features only to the SSLContext API

----------

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

From report at bugs.python.org  Sun May  1 21:21:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 May 2011 19:21:28 +0000
Subject: [issue11965] Simplify context manager in os.popen
In-Reply-To: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>
Message-ID: <1304277688.92.0.362609565824.issue11965@psf.upfronthosting.co.za>


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

Have you seen the comment on top of it? It says "Helper for popen() -- a proxy for a file whose close waits for the process".

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

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

From report at bugs.python.org  Sun May  1 21:36:44 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 01 May 2011 19:36:44 +0000
Subject: [issue11962] FreeBSD-AMD64 bot sporadic hanging
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304278604.73.0.14668267139.issue11962@psf.upfronthosting.co.za>


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

That might be another instance of this:

   http://thread.gmane.org/gmane.comp.python.devel/123698

You might want to bring this up on python-dev.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sun May  1 22:21:02 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 01 May 2011 20:21:02 +0000
Subject: [issue11975] Fix intersphinx-ing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

Intersphinx-ing of int, list, float, ... should work with ":class:`int`" (list, float, ...). Also, intersphinx-ing list methods, e.g. ":meth:`list.insert`", should work.

----------
assignee: docs at python
components: Documentation
messages: 134923
nosy: docs at python, jonash
priority: normal
severity: normal
status: open
title: Fix intersphinx-ing of built-in types (list, int, ...)

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

From report at bugs.python.org  Sun May  1 22:21:37 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 01 May 2011 20:21:37 +0000
Subject: [issue11976] Provide proper documentation for list data type
In-Reply-To: <1304281297.09.0.311318691729.issue11976@psf.upfronthosting.co.za>
Message-ID: <1304281297.09.0.311318691729.issue11976@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

Provide a proper `list` method reference (like the one for `dict`, http://docs.python.org/library/stdtypes.html#dict).

Right now, documentation about lists is spread over multiple topics (.rst files) and methods are documented in footnotes.

Also, intersphinx-ing and list methods is not possible -- :meth:`list.foo` does not create any links due to missing documentation. This is also related to #11975.

----------
assignee: docs at python
components: Documentation
messages: 134924
nosy: docs at python, jonash
priority: normal
severity: normal
status: open
title: Provide proper documentation for list data type

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

From report at bugs.python.org  Sun May  1 22:24:22 2011
From: report at bugs.python.org (Renaud Blanch)
Date: Sun, 01 May 2011 20:24:22 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1304281462.89.0.744828339959.issue11682@psf.upfronthosting.co.za>


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

As nick said, the repo only host a patch queue.
the patch itself is visible here:
https://bitbucket.org/rndblnch/cpython-pep380/qseries?apply=t&qs_apply=pep380

Or it can be download here in raw text:
https://bitbucket.org/rndblnch/cpython-pep380/raw/tip/pep380

I have documented how to apply the patch to a cpython clone here:
https://bitbucket.org/rndblnch/cpython-pep380/wiki

----------

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

From report at bugs.python.org  Sun May  1 22:25:27 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 01 May 2011 20:25:27 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

Various `int` attributes and methods seem undocumented (at least it does not work to intersphinx them):

* .conjugate
* .denominator
* .imag
* .numerator
* .real

----------
assignee: docs at python
components: Documentation
messages: 134926
nosy: docs at python, jonash
priority: normal
severity: normal
status: open
title: Document int.conjugate, .denominator, ...
versions: Python 2.7

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

From report at bugs.python.org  Sun May  1 22:31:47 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 01 May 2011 20:31:47 +0000
Subject: [issue11976] Provide proper documentation for list data type
In-Reply-To: <1304281297.09.0.311318691729.issue11976@psf.upfronthosting.co.za>
Message-ID: <1304281907.94.0.0875615637701.issue11976@psf.upfronthosting.co.za>


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

I'd go as far and say it is a duplicate. :)

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> Fix intersphinx-ing of built-in types (list, int, ...)

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

From report at bugs.python.org  Sun May  1 22:40:41 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 01 May 2011 20:40:41 +0000
Subject: [issue11974] Class definition gotcha.. should this be documented
	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1304282441.06.0.959284705407.issue11974@psf.upfronthosting.co.za>


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

Reclassifying as documentation issue.  I was certain we had something about this in the tutorial, but couldn't find it with a quick look.

It is in the FAQ ("how do I create static class data"), but that's not an obvious place to look.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, georg.brandl

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

From report at bugs.python.org  Sun May  1 23:33:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2011 21:33:20 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <E1QGeGS-0005TE-Gj@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c5e6f997730e by Victor Stinner in branch '3.1':
Issue #9756: When calling a method descriptor or a slot wrapper descriptor, the
http://hg.python.org/cpython/rev/c5e6f997730e

New changeset 4fc04f6a0731 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #9756: When calling a method descriptor or a slot wrapper
http://hg.python.org/cpython/rev/4fc04f6a0731

New changeset 8544561b7f04 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #9756: When calling a method descriptor or a slot wrapper
http://hg.python.org/cpython/rev/8544561b7f04

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

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

From report at bugs.python.org  Sun May  1 23:44:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2011 21:44:33 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <E1QGeRL-000697-Me@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 109687cc2c1e by Victor Stinner in branch '2.7':
(Merge 3.1) Issue #9756: When calling a method descriptor or a slot wrapper
http://hg.python.org/cpython/rev/109687cc2c1e

----------

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

From report at bugs.python.org  Sun May  1 23:51:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2011 21:51:28 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <E1QGeY0-0006fe-Es@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0db11682ea45 by Victor Stinner in branch '3.1':
Issue #9756: credit the author, Andreas St?hrk (Trundle)
http://hg.python.org/cpython/rev/0db11682ea45

New changeset a17f5c787cc0 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #9756: credit the author, Andreas St?hrk (Trundle)
http://hg.python.org/cpython/rev/a17f5c787cc0

New changeset ba8a8c47de7b by Victor Stinner in branch 'default':
(Merge 3.2) Issue #9756: credit the author, Andreas St?hrk (Trundle)
http://hg.python.org/cpython/rev/ba8a8c47de7b

New changeset bc5cd43c8d0c by Victor Stinner in branch '2.7':
(Merge 3.1) Issue #9756: credit the author, Andreas St?hrk (Trundle)
http://hg.python.org/cpython/rev/bc5cd43c8d0c

----------

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

From report at bugs.python.org  Sun May  1 23:52:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 21:52:29 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1304286749.46.0.0559366275484.issue9756@psf.upfronthosting.co.za>


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

> Ok, I'm sure that I have hardware issues, but I am also sure that the
> patch introduces random crashes, especially in
> test_descr.test_wrapper_segfault().

Forget my last messages: my Ubuntu box has serious memory issues. memtest86+ found 41 errors.

--

I applied Trundle's patch to 2.7, 3.1, 3.2 and 3.3, thanks for the fix.

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

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

From report at bugs.python.org  Mon May  2 00:04:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 22:04:18 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <BANLkTikCLg7yT1grQDTr05eAQOudkR_OMg@mail.gmail.com>
Message-ID: <1304287456.24646.0.camel@marge>


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

Le mardi 26 avril 2011 ? 22:20 +0000, Alexander Belopolsky a ?crit :
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Tue, Apr 26, 2011 at 6:09 PM, STINNER Victor <report at bugs.python.org> wrote:
> ..
> >
> > timemodule.c:
> >
> > PyDoc_STRVAR(module_doc,
> > "...
> > The tuple items are:\n\
> >  year (four digits, e.g. 1998)\n\
> > ...")
> >
> > => That's wrong. Example: time.gmtime(-55582200000).tm_year gives 208.
> 
> This is wrong regardless of this patch.   I don't mind fixing this,
> but it would be a different issue.  Can you suggest a change?  I would
> like the docstring to still inform the user that 1998 should be given
> as 1998 and not as 98.  Maybe s/four/all/?

"year (e.g. 1998)\n" is enough.

----------

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

From report at bugs.python.org  Mon May  2 00:21:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 22:21:10 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304288470.42.0.503566124252.issue10419@psf.upfronthosting.co.za>


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

Hey, I had already this bug and I also wrote a patch: copy_script-2.patch attached to #6011. It is very similar to build_scripts-binary_mode.patch (read the file in binary mode to avoid the encode/decode dance). But it checks also that the path to Python program is decodable from UTF-8 and from the script encoding.

?ric Araujo doesn't want to apply copy_script-2.patch on Python 3 before distutils2 is ported to Python 3 and included into Python (3.3): read msg124648. Five months later: distutils2 is not yet included to Python 3, the patch is not commited yet, and we have now a duplicate issue (and 3 patches for a single bug) :-)

This situation sucks. How can we move forward? What is the status of distutils2? Is it ported to Python3? Is it ready for an inclusion into Python3?

When distutils2 will be part of Python 3.3, should we fix distutils bugs or not? I suppose that few people use Python 3.3, maybe because it will not be released before August 2012 (PEP 398) :-) So users will continue to have this bug until everybody moves to 3.3 (or later)...

I think that we should fix this bug today. I don't really care of distutils2 today because it is not yet part of Python.

----------

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

From report at bugs.python.org  Mon May  2 00:25:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 22:25:12 +0000
Subject: [issue11361] suggestion for os.kill(pid,CTRL_C_EVENT) in tests
In-Reply-To: <1298986221.06.0.20392871991.issue11361@psf.upfronthosting.co.za>
Message-ID: <1304288712.34.0.715231280759.issue11361@psf.upfronthosting.co.za>


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

Oh, if the process is able to handle CTRL+c on Windows, it means that faulthandler.register() could be used on Windows. While developing the faulthandler module, I tried all signals but I was only able to handle SIGSEGV, SIGABRT, SIGBUS and SIGILL on Windows. And all of these signals are reserved to faulthandler.enable() function. So faulthandler.register() is just not compiled on Windows.

If SetConsoleCtrlHandler() is really useful, we should maybe add something to the signal module to give access to this function.

----------

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

From report at bugs.python.org  Mon May  2 00:27:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 01 May 2011 22:27:49 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1304207017.82.0.684890313364.issue10419@psf.upfronthosting.co.za>
Message-ID: <4DBDDE60.2010905@netwok.org>


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

> Apparently setuptools.command.easy_install.get_script_header() imports
> distutils.command.build_scripts.first_line_re and checks if this regex
> matches a str object, which results in TypeError. If breaking
> compatibility is not acceptable, then the surrogateescape patch should
> be applied.

Setuptools is not compatible with 3.x TTBOMK; distribute is, but could
be fixed quickly, so there is no compat problem with this (these)
library(ries).  However, the public/private status of first_line_re is
unclear, so there could be other projects out there depending on its
type.  Given that there is already one patch in distutils that uses
surrogateescape, I think we could accept another similar patch.

----------

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

From report at bugs.python.org  Mon May  2 00:35:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 01 May 2011 22:35:59 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1304288470.42.0.503566124252.issue10419@psf.upfronthosting.co.za>
Message-ID: <4DBDE04C.4060209@netwok.org>


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

is not commited yet,
> and we have now a duplicate issue (and 3 patches for a single bug) :-)
Feel free to close duplicate issues.

Looks like you?re not following PyCon reports, or Tarek?s mails to
python-dev.  distutils2 has been ported to 3.3 under the name
?packaging?; there is a repo on bitbucket (tarek/cpython) with this
code.  Tarek will produce a patch from this repo and push it to the main
repository soon.

Yes: we?ll fix bugs in packaging and distutils.  Packaging releases will
be backported for 2.4-3.2 under the name ?distutils2?.

----------

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

From report at bugs.python.org  Mon May  2 00:37:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2011 22:37:46 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <E1QGfGr-0001CY-J6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dc65d1b99dff by Benjamin Peterson in branch '3.1':
note abcs of int and float (closes #11977)
http://hg.python.org/cpython/rev/dc65d1b99dff

New changeset 5b315145e525 by Benjamin Peterson in branch '2.7':
note abcs of int and float (closes #11977)
http://hg.python.org/cpython/rev/5b315145e525

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon May  2 00:47:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 22:47:51 +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: <1304290071.89.0.961612219597.issue11859@psf.upfronthosting.co.za>


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

The issue is race condition and was rare (I only saw it once on FreeBSD 7.2 3.x buildbot). I suppose that it is fixed, I'm unable to check (I am unable to reproduce the bug in my FreeBSD 8 VM). Reopen the issue if it is not fixed yet.

----------
dependencies:  -expose signalfd(2) and pthread_sigmask in the signal module
resolution:  -> fixed

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

From report at bugs.python.org  Mon May  2 01:05:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 May 2011 23:05:39 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <1304291139.51.0.145362298189.issue11927@psf.upfronthosting.co.za>


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

> Should we add a unit test for this as well?

True, a simple test could be added to test_smtpnet.

----------

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

From report at bugs.python.org  Mon May  2 01:09:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 23:09:24 +0000
Subject: [issue10922] Unexpected exception when calling
	function_proxy.__class__.__call__(function_proxy)
In-Reply-To: <1295230218.02.0.641570555776.issue10922@psf.upfronthosting.co.za>
Message-ID: <1304291364.86.0.983642798202.issue10922@psf.upfronthosting.co.za>


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

> I think this is a duplicate of issue #9756

Yes it is and the issue is now fixed. The example now fails with the correct exception:

Traceback (most recent call last):
  File "?x.py", line 12, in <module>
    p.__class__.__call__(p)
TypeError: descriptor '__call__' requires a 'function' object but received a 'Proxy'

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed
superseder:  -> Crash with custom __getattribute__

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

From report at bugs.python.org  Mon May  2 01:15:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2011 23:15:32 +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: <E1QGfrO-0003WM-F6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cb464f8fb3a1 by Victor Stinner in branch '3.1':
Issue #11277: mmap calls fcntl(fd, F_FULLFSYNC) on Mac OS X to get around a
http://hg.python.org/cpython/rev/cb464f8fb3a1

New changeset e9d298376dde by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #11277: mmap.mmap() calls fcntl(fd, F_FULLFSYNC) on Mac OS X
http://hg.python.org/cpython/rev/e9d298376dde

New changeset d578fdc9b157 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11277: mmap.mmap() calls fcntl(fd, F_FULLFSYNC) on Mac OS X
http://hg.python.org/cpython/rev/d578fdc9b157

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

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

From report at bugs.python.org  Mon May  2 01:20:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 May 2011 23:20:55 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1304292055.76.0.633731309759.issue8808@psf.upfronthosting.co.za>


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

Thanks for the patch. Comments:
- the keyfile / certfile pair and the context parameter should be mutually exclusive (see e.g. the POP3_SSL constructor in Lib/poplib.py)
- I don't think the remote test server used in test_imaplib supports client certificates, it probably just ignores them; that said, it's better than nothing
- you have a misindented line in test_logincapa
- since we're using a remote, third-party test server, it may be better not to do any spurious connects (in the current patch, a first connection is established in the setUp() and then ignored since another one is established in the test body)
- you need to update the documentation in Doc/library/imaplib.rst

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

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

From report at bugs.python.org  Mon May  2 01:22:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 23:22:41 +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: <1304292161.49.0.705266735254.issue11277@psf.upfronthosting.co.za>


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

I am not able to check the fix, but the buildbots are :-)

What should be done for Python 2.7? In Python 2.7, zlib.crc32() stores the buffer length into an int (so the maximum length is INT_MAX), and so test_zlib doesn't test a (sparse) file of 4 GB (ChecksumBigBufferTestCase).

But I suppose that mmap bug can also occur with a file of 2 GB.

@sdaoden: Can you try on Python 2.7?

----------

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

From report at bugs.python.org  Mon May  2 01:27:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 23:27:46 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304292466.8.0.559536418539.issue11888@psf.upfronthosting.co.za>


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

Oh... math.log() has an optional second argument: base. math.log(x, 2). But it is equivalent as math.log(x) / math.log(2) in Python. math.log(x, 2) is implemented as:
  num=math.log(x)
  den=math.log(2)
  return num / den
where num and den are Python floats (64 bits).

So we don't benefit from 80 bits float used internally in x87.

----------

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

From report at bugs.python.org  Mon May  2 01:46:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 23:46:18 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1304293578.32.0.794379613663.issue6501@psf.upfronthosting.co.za>


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

> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> LookupError: unknown encoding: cp0

That's a bug in os.device_encoding(): os.device_encoding(sys.stdout.fileno()) should return None if the application has no console (if sys.stdout is not a Windows console stream).

Attached device_encoding.patch should fix this issue. (I didn't test the patch yet.)

----------
Added file: http://bugs.python.org/file21849/device_encoding.patch

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

From report at bugs.python.org  Mon May  2 01:52:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2011 23:52:20 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1304293940.46.0.961727107077.issue6501@psf.upfronthosting.co.za>


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

> On a Western Windows, I suggest
>    PYTHONIOENCODING=cp1252:backslashreplace

Why using this very small charset whereas a web server can use UTF-8?

I don't think that using backslashreplace on stdout is a good idea.

> But 
>    PYTHONIOENCODING=mbcs
> is also OK, except that characters outside the Windows code
> page will be replaced with '?'

Starting at Python 3.2, you should use mbcs:replace to replace unencodable characters by '?'. The strict error handler is now strict: it raises a UnicodeEncodeError if a character is not encodable to mbcs.

Note: mbcs is the ANSI code page.

--

Using device_encoding.patch, I suppose that sys.std* streams will use the ANSI code page (mbcs, which is the code page 1252 on a Western Windows setup) in grahamd's usecase (Python program running in Apache).

----------

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

From report at bugs.python.org  Mon May  2 02:05:59 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 02 May 2011 00:05:59 +0000
Subject: [issue11270] logging: RotatingFileHandler crash when opening the
	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1304294759.62.0.398860104475.issue11270@psf.upfronthosting.co.za>


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

There have been no widespread reports of rotating file handlers being unusable under Windows. This is a Windows limitation that generally needs to be worked around, it's not limited to logging applications only.

It's possible to copy a set of rotated files to another location for more leisurely examination, though that could also cause failures depending on how the files are opened for copying.

If this option is not open to you, you can still use a rotating file handler base class, but just reimplement the doRollover() method to implement any other strategy you like of dealing with files held open by other processes. This was suggested in an earlier response - is there any reason it wouldn't work for you?

----------

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

From report at bugs.python.org  Mon May  2 07:05:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 May 2011 05:05:28 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304312728.05.0.918648819354.issue11887@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I thought some more about this and I'm -0.5.
The reasons are:
  * the patch introduces code/complexity in _baseAssertEqual and other places, using catch_warnings to change and restore the warning filters at every call;
  * this is needed only when Python is run with -b/-bb and that is quite uncommon (afaik);
  * even if this is not fixed, a test suite that passes all the tests without -b/-bb will most likely pass with -b/-bb[0];
  * if there are failing tests with -b/-bb, it's usually possible to remove the -b/-bb and fix them before re-adding -bb[1];

[0]: the only exception I can think of is something like self.assertNotEqual(a_string, a_bytestring): this passes without -bb but fails with a BytesWarning with -bb. This tests is "wrong" though, because string are always not equal to bytestrings, regardless of their values. If one wants to make sure that a_string is not a bytestring, the correct way to do it is assertNotIsInstance(a_string, bytes).  self.assertEqual(a_string, a_bytestring) fails already without -bb so, even if with -bb the traceback is less useful, it can/should be fixed without -b/-bb.
To prove this further the whole Python test suite passes with -bb.

[1]: that might indeed not be the case (e.g. with our buildbots is not easy to change flags), but I'm still not sure it's worth patching this just to have a better traceback in case of a test failure that accidentally involves bytes/string comparison on a Python running with -bb on an environment where changing the flags is not easy (i.e. a rather obscure corner case).

----------

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

From report at bugs.python.org  Mon May  2 07:26:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 May 2011 05:26:39 +0000
Subject: [issue11974] Class definition gotcha.. should this be documented
	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1304313999.88.0.485176262453.issue11974@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

A good place where to add it would be http://docs.python.org/tutorial/classes.html.
It might even get a small "Differences between class and instance attribute" section.

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

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

From report at bugs.python.org  Mon May  2 09:06:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 May 2011 07:06:09 +0000
Subject: [issue11975] Fix intersphinx-ing of built-in types (list, int, ...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1304319969.5.0.108629077655.issue11975@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #4966 and #11976.

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

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

From report at bugs.python.org  Mon May  2 09:06:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 May 2011 07:06:50 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1304320010.54.0.0255392294633.issue4966@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #11975 and #11976.

----------

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

From report at bugs.python.org  Mon May  2 10:10:16 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 02 May 2011 08:10:16 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304323816.82.0.472384255414.issue11967@psf.upfronthosting.co.za>


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

Ok, I'm closing this as won't fix. Mark is our authority on these matters, and having two spellings for this fairly uncommon operation seems enough.

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

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

From report at bugs.python.org  Mon May  2 10:26:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 08:26:10 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1304312728.05.0.918648819354.issue11887@psf.upfronthosting.co.za>
Message-ID: <201105021026.07906.victor.stinner@haypocalc.com>


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

Le lundi 02 mai 2011 07:05:28, vous avez ?crit :
>   * the patch introduces code/complexity in _baseAssertEqual and other
> places, using catch_warnings to change and restore the warning filters at
> every call;

Yes, and what is the problem? I think that it is cheap: it copies a list, 
prepends an item to a short list, and then copies a reference (the previous 
list).

I think that the patch is simple (it adds 3 "with+simplefilter") and it 
doesn't add "complexity", or you should define what complexity is :-)

> * this is needed only when Python is run with -b/-bb and that
> is quite uncommon (afaik);

Buildbots use "make buildbottest" which run python with -bb (which is a good 
idea!). So all buildbots already use -bb since long time.

I forgot the explain the usecase: I don't remember correctly, but a test 
failed on a buildbot, and I was unable to get more information because 
unittest "failed" too.

> * even if this is not fixed, a test suite that
> passes all the tests without -b/-bb will most likely pass with -b/-bb[0];

No. You have usually more failures with -bb than without any -b flag. Not in 
the test itself, but in a function called by the test.

> * if there are failing tests with -b/-bb, it's usually possible to remove
> the -b/-bb and fix them before re-adding -bb[1];

A test may only fail with -bb.

Anyway, my problem is to be able to get more informations on a failure in a 
buildbot. I cannot change (easily) -bb flags on the buildbots (and I don't 
want to do that). When something goes wrong on a buildbot, in some cases it is 
very hard to reproduce the failure on my own computer. I want as much 
information as possible.

----------

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

From report at bugs.python.org  Mon May  2 11:10:20 2011
From: report at bugs.python.org (Stefan Pfeiffer)
Date: Mon, 02 May 2011 09:10:20 +0000
Subject: [issue11839] argparse: unexpected behavior of default for
	FileType('w')
In-Reply-To: <1302638190.31.0.523851627026.issue11839@psf.upfronthosting.co.za>
Message-ID: <1304327420.01.0.144324544811.issue11839@psf.upfronthosting.co.za>


Stefan Pfeiffer <stefan.pfeiffer at gmail.com> added the comment:

Happens in 3.2, too...

Would be nice to see that fixed.

Stefan

----------
nosy: +Stefan.Pfeiffer

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

From report at bugs.python.org  Mon May  2 12:56:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 May 2011 10:56:20 +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: <1304333780.29.0.605823458328.issue11975@psf.upfronthosting.co.za>


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

I changed the title: intersphinx is a Sphinx extension used to links to foreign documentation, not create links inside one doc (as I understand the request is).

----------
nosy: +eric.araujo
stage:  -> needs patch
title: Fix intersphinx-ing of built-in types (list, int, ...) -> Fix referencing of built-in types (list, int, ...)
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May  2 12:58:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 02 May 2011 10:58:28 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304201710.96.0.0426989644523.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110502105818.GA45049@sherwood.local>


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

On Sun,  1 May 2011 00:15:11 +0200, R. David Murray <report at bugs.python.org> wrote:
> The problem with this patch is that it would also show 'new
> mail' if what had in fact happened was that a message had been
> *deleted* (see the comments at the beginning of the flush
> method).  So actually fixing this is a bit more complicated.

Well i don't think so because MUA's do some further checks,
like checking the size and of course the status of each mail;
some indeed use the mtime as an entry-gate for further inspection.
And deleting an entry should surely pass that gate, too.

Please do see the file mbox.c of the mutt(1) source repository,
which in fact seems to have been used as an almost copy-and-paste
template for the implementation of large parts of mailbox.py.

But note that i just search less than five minutes in mailbox.py
to find a place where i can add the code of the patch (after
i've added an identical workaround for my S-Postman), so of course
it may not catch all cases.  One error is obvious: it also sets the
mtime for that Babylon format.  I don't use emacs and i'm
a buddhist so i don't care about that Babylon mess anyway.
Right?

> A proper fix for this should also consider fixing issue 7359.

Hm.  #7359 refers to misconfiguration, not to Python or
mailbox.py.  Maybe Doc/library/mailbox.rst should be adjusted to
give users which are new to UNIX a hint about ,group mail` and the
set-group-ID on directories?  I think this would really be a good
thing?!?!  Should i open an issue on that?

But again, mailbox.py reflects almost one-to-one (except for the
naive file lock handling in comparison and AFAIK) mutt(1)'s
mbox.c, and i think that if mutt(1) does
create-temp-work-work-work-rename then this should be ok for
mailbox.py, too.

Did you know that ,bin Laden` ment ,am loading` in german?

----------

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

From report at bugs.python.org  Mon May  2 13:03:30 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 02 May 2011 11:03:30 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304201710.96.0.0426989644523.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110502110321.GB45049@sherwood.local>


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

I'll attach a patch with a clearer comment (entry-gate instead
"new mail"), i.e. the comment now reflects what MUAs really do.

----------
Added file: http://bugs.python.org/file21850/11935.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11935>
_______________________________________
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -692,6 +692,13 @@
         self._file = open(self._path, 'rb+')
         self._toc = new_toc
         self._pending = False
+        # Set modification time to be after access time so that MMDF and MBOX
+        # mail readers detect changes (or perform further inspection to do so)
+        try:
+            currtime = time.time()
+            os.utime(self._path, (currtime-3, currtime))
+        except:
+            pass
         if self._locked:
             _lock_file(self._file, dotlock=False)
 

From report at bugs.python.org  Mon May  2 13:05:53 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 02 May 2011 11:05:53 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304334353.29.0.604072723823.issue11935@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21795/mailbox.diff

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

From report at bugs.python.org  Mon May  2 13:27:52 2011
From: report at bugs.python.org (Jonas H.)
Date: Mon, 02 May 2011 11:27:52 +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: <1304335672.11.0.434241878444.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Actually I need to be able to intersphinx (because my documentation work is not the Python docs :-) but I guess it boils down to the same problem of incomplete Sphinx module/class indices.

----------

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

From report at bugs.python.org  Mon May  2 13:39:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 May 2011 11:39:08 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <E1QGrT0-0000v9-EH@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c02c78d93a2e by ?ric Araujo in branch '2.7':
Fix double use of f.close().
http://hg.python.org/cpython/rev/c02c78d93a2e

----------

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

From report at bugs.python.org  Mon May  2 14:12:14 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 02 May 2011 12:12:14 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304338334.39.0.749638765621.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

To revive this issue, I tried to write a unit test to verify the behaviour. Onfurtunately, the test doesn't work and I don't understand why. I hope, someone here is more enlightend than me...
(files: server.py, client.py)

----------
Added file: http://bugs.python.org/file21851/server.py

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

From report at bugs.python.org  Mon May  2 14:12:28 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 02 May 2011 12:12:28 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304338348.65.0.712590718876.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

(client.py)

----------
Added file: http://bugs.python.org/file21852/client.py

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

From report at bugs.python.org  Mon May  2 14:12:41 2011
From: report at bugs.python.org (Alexander Vrchoticky)
Date: Mon, 02 May 2011 12:12:41 +0000
Subject: [issue11270] logging: RotatingFileHandler crash when opening the
	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1304338361.12.0.626308187498.issue11270@psf.upfronthosting.co.za>


Alexander Vrchoticky <Alexander.Vrchoticky at gmx.at> added the comment:

Thank you for the reply. I'll look into subclassing, but I am not convinced that there is a way to fix this: The basic problem is that one viewer has a file open, and the logger would like to start a new file with the same name.

What would work, is to generate file names based on (say) the current day, as in Logfile-20110502.txt. This design avoids the problem that we're rolling over to files of the same name, but it is a different beast from RotatingFileHandler.

That said, I think this issue should be reopened: RotatingFileHandler is a part of the standard library, and Windows is a supported platform.
If the logger crashes because somebody is looking at a log file, this is a valid bug.

----------

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

From report at bugs.python.org  Mon May  2 14:38:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 May 2011 12:38:18 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304339898.67.0.459891477613.issue11887@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I think that the patch is simple (it adds 3 "with+simplefilter") and it
> doesn't add "complexity", or you should define what complexity is :-)

The patch is indeed quite simple. but with it half of the code in _baseAssertEqual will be to deal with warnings for this corner case.

> Buildbots use "make buildbottest" which run python with -bb

Yes, but "make buildbottest" is used just by the buildbots afaik.

> No. You have usually more failures with -bb than without any -b flag.
> Not in test itself, but in a function called by the test.

That's what I meant, the tests will still work with -bb and the failures will be elsewhere (i.e. the patch won't change anything here).

> A test may only fail with -bb.

If the failure is in the test, I would say that the test is probably wrong (see e.g. the assertNotEqual example in my previous message), if the failure is elsewhere the patch won't change anything.

> Anyway, my problem is to be able to get more informations on a 
> failure in a buildbot. I cannot change (easily) -bb flags on the
> buildbots [...]

On this I agree (that's why I'm -0.5 and not -1), but as I said it's a very specific situation, and my gut feeling is that it might not be worth fixing it.

----------

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

From report at bugs.python.org  Mon May  2 15:20:22 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 02 May 2011 13:20:22 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304342422.87.0.948967979978.issue11887@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Rather than fiddling with the warnings filters, wouldn't it be easier to just catch BytesWarning and return False in that case?

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

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

From report at bugs.python.org  Mon May  2 15:46:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 02 May 2011 13:46:10 +0000
Subject: [issue11978] Report correct coverage.py data for tests that invoke
	subprocesses
In-Reply-To: <1304343970.06.0.71963253791.issue11978@psf.upfronthosting.co.za>
Message-ID: <1304343970.06.0.71963253791.issue11978@psf.upfronthosting.co.za>


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

http://nedbatchelder.com/code/coverage/subprocess.html describes how to instruct a test suite that spawns subprocesses to correctly report coverage data for code covered only in those subprocesses.

regrtest currently doesn't do this, so modules that use subprocesses to run their tests may report inaccurate coverage numbers when using this tool (as recommended in the devguide). (Those numbers are irredeemably inaccurate when it comes to regrtest's own coverage assessment)

It may be better to build explicit invocation of coverage.py when regrtest is run under coverage.py into test.script_helper rather than trying to use the implicit mechanism though (as neither sitecustomize nor a .pth file are particularly good ideas when running Python's own test suite).

----------
messages: 134967
nosy: brett.cannon, ncoghlan, nedbat
priority: normal
severity: normal
status: open
title: Report correct coverage.py data for tests that invoke subprocesses
type: feature request

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

From report at bugs.python.org  Mon May  2 15:49:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 13:49:57 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304344197.61.0.971758881672.issue11887@psf.upfronthosting.co.za>


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

> Rather than fiddling with the warnings filters, wouldn't it be easier
> to just catch BytesWarning and return False in that case?

It's another possible solution, but it would display a warning using python -b.

----------

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

From report at bugs.python.org  Mon May  2 15:50:52 2011
From: report at bugs.python.org (Xavier Morel)
Date: Mon, 02 May 2011 13:50:52 +0000
Subject: [issue11979] Minor improvements to the Sockets readme: typos,
	wording and sphinx features usage
In-Reply-To: <1304344252.29.0.0856006463682.issue11979@psf.upfronthosting.co.za>
Message-ID: <1304344252.29.0.0856006463682.issue11979@psf.upfronthosting.co.za>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

First patch fixes a typo ("the reads a reply" -> "then reads a reply") and ? I believe ? improves the wording of a pair of sentences.

Second patch makes use of Sphinx's ``:abbr:`` role, and removes some period which I think are redundant with the use of ``::``

----------
assignee: docs at python
components: Documentation
files: wording
messages: 134970
nosy: docs at python, xmorel
priority: normal
severity: normal
status: open
title: Minor improvements to the Sockets readme: typos, wording and sphinx features usage
versions: Python 3.3
Added file: http://bugs.python.org/file21853/wording

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

From report at bugs.python.org  Mon May  2 15:51:11 2011
From: report at bugs.python.org (Xavier Morel)
Date: Mon, 02 May 2011 13:51:11 +0000
Subject: [issue11979] Minor improvements to the Sockets readme: typos,
	wording and sphinx features usage
In-Reply-To: <1304344252.29.0.0856006463682.issue11979@psf.upfronthosting.co.za>
Message-ID: <1304344271.41.0.382725582685.issue11979@psf.upfronthosting.co.za>


Changes by Xavier Morel <xavier.morel at masklinn.net>:


Added file: http://bugs.python.org/file21854/sphinx-features

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

From report at bugs.python.org  Mon May  2 15:51:25 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 02 May 2011 13:51:25 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304344285.11.0.414801399253.issue10419@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

copy_script-2.patch uses os.fsencode(), which doesn't exist in Python 3.1.

----------

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

From report at bugs.python.org  Mon May  2 15:53:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 13:53:21 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304344401.86.0.166167616777.issue10419@psf.upfronthosting.co.za>


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

> copy_script-2.patch uses os.fsencode(), which doesn't exist in Python 3.1.

Correct, with Python 3.1, you can use filename.encode(sys.getfilesystemencoding(), 'surrogateescape'). But you must use os.fsencode() with Python >= 3.2 because on Windows, you cannot use surrogateescape with MBCS (you should use the strict error handler).

----------

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

From report at bugs.python.org  Mon May  2 15:56:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 13:56:57 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304344617.18.0.584707095087.issue8407@psf.upfronthosting.co.za>


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

test_signal.PthreadSigmaskTests fails on Mac OS X.

http://www.python.org/dev/buildbot/all/builders/PPC Leopard 3.x/builds/1785/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/PPC Tiger 3.x/builds/1748/steps/test/logs/stdio
---
[186/354] test_signal
make: *** [buildbottest] User defined signal 1
----

http://www.python.org/dev/buildbot/all/builders/x86 Tiger 3.x/builds/2429/steps/test/logs/stdio
---
Re-running test 'test_signal' in verbose mode
...
test_arguments (test.test_signal.PthreadSigmaskTests) ... ok
test_block_unlock (test.test_signal.PthreadSigmaskTests) ... make: *** [buildbottest] User defined signal 1
program finished with exit code 2
---

----------

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

From report at bugs.python.org  Mon May  2 15:57:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 02 May 2011 13:57:58 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1304292161.49.0.705266735254.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110502135748.GA14021@sherwood.local>


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

On Mon,  2 May 2011 01:22:41 +0200, STINNER Victor <report at bugs.python.org> wrote:
> @sdaoden: Can you try on Python 2.7?

@haypo: Python 2.7 is absolute horror.
But i tried and produced a (terrible - i don't know the test
framework and that test_support stuff seems to have been changed
a lot since 2.7) 2 gigabyte+ big buffer test for 2.7.
(Of course: even though Python uses int, ZLib uses uInt.)
It took some time because i fell over #1202 from 2007 unprepared.

The (nasty) test works quite well on Apple, which is not such
a big surprise, because Apple's OS X is especially designed for
artists which need to work on large files, like video+ cutters,
sound designers with sample databases etc., so i would be
terribly disappointed if that wouldn't work!  Apple even
propagandize OS X for, and makes money with that very application
task - i really couldn't understand your doubts here.

----------
Added file: http://bugs.python.org/file21855/11277-27.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -1,10 +1,16 @@
 import unittest
-from test import test_support
+from test.test_support import TESTFN, run_unittest, import_module, unlink, requires
+from test.test_support import precisionbigmemtest, _1G, _2G
 import binascii
 import random
-from test.test_support import precisionbigmemtest, _1G
+import sys
 
-zlib = test_support.import_module('zlib')
+try:
+    import mmap
+except ImportError:
+    mmap = None
+
+zlib = import_module('zlib')
 
 
 class ChecksumTestCase(unittest.TestCase):
@@ -66,6 +72,32 @@
                          zlib.crc32('spam',  (2**31)))
 
 
+# Issue #10276 - check that inputs >=4GB are handled correctly.
+# Backport to 2.7 due to Issue #11277: why not verify INT32_MAX on 2.7?
+# Also take care of Issue #1202 here
+class ChecksumBigBufferTestCase(unittest.TestCase):
+    @unittest.skipUnless(mmap, "mmap() is not available.")
+    def test_big_buffer(self):
+        if sys.platform[:3] == 'win' or sys.platform == 'darwin':
+            requires('largefile',
+                'test requires %s bytes and a long time to run' % str(_2G+2))
+        try:
+            with open(TESTFN, "wb+") as f:
+                f.seek(_2G-2)
+                f.write("asdf")
+                f.flush()
+                try:
+                    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
+                    self.assertEqual(zlib.crc32(m), -2072986226)
+                    self.assertEqual(zlib.adler32(m), -2072641121)
+                finally:
+                    m.close()
+        except (IOError, OverflowError):
+            raise unittest.SkipTest("filesystem doesn't have largefile support")
+        finally:
+            unlink(TESTFN)
+
+
 class ExceptionTestCase(unittest.TestCase):
     # make sure we generate some expected errors
     def test_badlevel(self):
@@ -546,8 +578,9 @@
 
 
 def test_main():
-    test_support.run_unittest(
+    run_unittest(
         ChecksumTestCase,
+        ChecksumBigBufferTestCase,
         ExceptionTestCase,
         CompressTestCase,
         CompressObjectTestCase

From report at bugs.python.org  Mon May  2 15:58:12 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 02 May 2011 13:58:12 +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: <1304344692.52.0.976017476975.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21673/11277.zsum32.c

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

From report at bugs.python.org  Mon May  2 16:12:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 02 May 2011 14:12:08 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304345528.8.0.173874686509.issue11887@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm OK with that - I'd actually suggest explicitly *emitting* a warning when the error is suppressed under -bb, as Ezio is right that even tests should be keeping their bytes/str separation straight. I don't like completely suppressing warnings/errors when a user has explicitly requested them.

I'd also be OK with a filtering approach that coerced the handling to "default" rather than "ignore" (although that require a bit more work to keep unittest from acting as though -b was always set on the command line).

----------

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

From report at bugs.python.org  Mon May  2 16:31:38 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 02 May 2011 14:31:38 +0000
Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by
	one character
In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za>
Message-ID: <1304346698.45.0.918863283611.issue1104@psf.upfronthosting.co.za>


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

This patch seems okay to me, as far as it goes. I'd like to hear Martin's feedback, but I think it should be committed.

And I realize the rest of this message doesn't apply to the patch, but it does address other problems in summary_getproperty(). At least one of these led to the original problem with the truncated character.

1. It's not clear to me that the malloc() call only occurs if the type is VT_LPSTR. But that's the only case where free() is called. I think it would be better to move the call to free() to a cleanup section at the end of the function.

2. The status is never checked for success, just for one specific failure. I think both calls to MsiSummaryInfoGetProperty should be looking for ERROR_SUCCESS.

3. I don't think VT_FILETIME is special enough for its own error message. It should just be caught with all other unknown types.

Maybe these last 3 should get their own new issue.

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

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

From report at bugs.python.org  Mon May  2 16:53:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 14:53:19 +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: <1304347999.92.0.289179254047.issue11277@psf.upfronthosting.co.za>


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

> @haypo: Python 2.7 is absolute horror.

Oh, zlib doesn't use PY_SSIZE_T_CLEAN in Python 2.7.

11277-27.1.diff contains "# Issue #10276 - check that inputs >=4GB are handled correctly.". I don't understand this comment because the test uses a buffer of 2 GB + 2 bytes.

How is it possible to pass a buffer of 2 GB+2 bytes to crc32(), whereas it stores the size into an int. The maximum size is INT_MAX which is 2 GB-1 byte. It looks like the "i" format of PyArg_ParseTuple() doesn't check for integer overflow => issue #8651. This issue was fixed in 3.1, 3.2 and 3.3, but not in Python 2.

Should we fix Python 2.7?
 - backport issue #8651
 - use PY_SSIZE_T_CLEAN in zlibmodule.c

----------

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

From report at bugs.python.org  Mon May  2 16:59:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 14:59:57 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304348397.15.0.0866431389897.issue8407@psf.upfronthosting.co.za>


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

Update signalfd patch.

----------
Added file: http://bugs.python.org/file21856/signalfd-2.patch

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

From report at bugs.python.org  Mon May  2 17:00:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 15:00:01 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304348401.69.0.186618618296.issue8407@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21841/signalfd.patch

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

From report at bugs.python.org  Mon May  2 17:07:10 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 May 2011 15:07:10 +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: <1304348830.57.0.516647494104.issue11975@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

FWIW, :func:`int/float` work IIRC.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon May  2 17:07:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 15:07:40 +0000
Subject: [issue11779] test_mmap.test_large_offset() timeout (1 hour) on "AMD64
	Snow Leopard 3.x" buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1304348860.91.0.842748014614.issue11779@psf.upfronthosting.co.za>


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

I commited Steffen's patch for mmap. We will see if it improves the situation.

New changeset d578fdc9b157 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11277: mmap.mmap() calls fcntl(fd, F_FULLFSYNC) on Mac OS X
http://hg.python.org/cpython/rev/d578fdc9b157

----------

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

From report at bugs.python.org  Mon May  2 17:14:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 15:14:12 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1304348397.15.0.0866431389897.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304349229.3498.8.camel@localhost.localdomain>


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

> Update signalfd patch.
> 
> ----------
> Added file: http://bugs.python.org/file21856/signalfd-2.patch

- In the tests, you don't need sys.exc_info(), just
"except XXXError as e".
- In the doc, you wrote "file description" instead of "file descriptor"
- In test_out_of_range_signal, you should use assertRaises

----------

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

From report at bugs.python.org  Mon May  2 17:20:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 15:20:58 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304349658.7.0.351177118122.issue8407@psf.upfronthosting.co.za>


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

Fixed: updated patch (version 3).

----------
Added file: http://bugs.python.org/file21857/signalfd-3.patch

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

From report at bugs.python.org  Mon May  2 17:21:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 15:21:05 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304349665.53.0.658227557829.issue8407@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21856/signalfd-2.patch

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

From report at bugs.python.org  Mon May  2 17:26:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 15:26:17 +0000
Subject: [issue11361] suggestion for os.kill(pid,CTRL_C_EVENT) in tests
In-Reply-To: <1298986221.06.0.20392871991.issue11361@psf.upfronthosting.co.za>
Message-ID: <1304349977.05.0.672753651279.issue11361@psf.upfronthosting.co.za>


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

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4483/steps/test/logs/stdio
----------
test test_os failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_os.py", line 1177, in test_CTRL_BREAK_EVENT
    self._kill_with_event(signal.CTRL_BREAK_EVENT, "CTRL_BREAK_EVENT")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_os.py", line 1155, in _kill_with_event
    self.fail("subprocess did not stop on {}".format(name))
AssertionError: subprocess did not stop on CTRL_BREAK_EVENT
----------

----------

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

From report at bugs.python.org  Mon May  2 17:30:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 15:30:16 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304350216.31.0.481676506421.issue10496@psf.upfronthosting.co.za>


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

> I would like Tarek to make a call on this.

So Tarek, what do you think?

----------

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

From report at bugs.python.org  Mon May  2 17:35:22 2011
From: report at bugs.python.org (Jonas H.)
Date: Mon, 02 May 2011 15:35:22 +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: <1304350522.69.0.216617511154.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Indeed they do; but documentation writers need to know that `int()` and `float()` are functions, which is counterintuitive. (and a CPython implementation detail)

----------

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

From report at bugs.python.org  Mon May  2 17:36:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 May 2011 15:36:59 +0000
Subject: [issue11975] Fix referencing of built-in types (list, int, ...)
In-Reply-To: <1304350522.69.0.216617511154.issue11975@psf.upfronthosting.co.za>
Message-ID: <BANLkTikXyOo-Mq_a1HsFyEx3=zzsgHfaHA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/2 Jonas H. <report at bugs.python.org>:
>
> Jonas H. <jonas at lophus.org> added the comment:
>
> Indeed they do; but documentation writers need to know that `int()` and `float()` are functions, which is counterintuitive. (and a CPython implementation detail)

They're not even functions, just documented as such.

----------

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

From report at bugs.python.org  Mon May  2 17:43:20 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 02 May 2011 15:43:20 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304351000.02.0.819210968036.issue10496@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

As discussed w/ Victor, a process should be able to run Python even if its user does not have a home.

So the call to _getuserbase() should be protected. 

But then we have to control that all the code that uses  CONFIG_VARS['userbase'] is protected when the value is not set.

I am thinking about per-user installation and such things: we need to make sure everything is checking this.

----------

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

From report at bugs.python.org  Mon May  2 18:31:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 May 2011 16:31:50 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <E1QGw2B-0000Mq-AS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e6f6ac8c2502 by Alexander Belopolsky in branch 'default':
Issue #11930: Remove deprecated time.accept2dyear.
http://hg.python.org/cpython/rev/e6f6ac8c2502

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

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

From report at bugs.python.org  Mon May  2 18:34:52 2011
From: report at bugs.python.org (Johan Euphrosine)
Date: Mon, 02 May 2011 16:34:52 +0000
Subject: [issue11980] zipfile.ZipFile.write should accept fp as argument
In-Reply-To: <1304354092.27.0.477434523561.issue11980@psf.upfronthosting.co.za>
Message-ID: <1304354092.27.0.477434523561.issue11980@psf.upfronthosting.co.za>


New submission from Johan Euphrosine <proppy at google.com>:

Currently it only accept a filename (and writestr only accept bytes).

----------
components: Library (Lib)
messages: 134989
nosy: Johan.Euphrosine
priority: normal
severity: normal
status: open
title: zipfile.ZipFile.write should accept fp as argument
type: feature request
versions: Python 3.4

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

From report at bugs.python.org  Mon May  2 18:36:57 2011
From: report at bugs.python.org (Johan Euphrosine)
Date: Mon, 02 May 2011 16:36:57 +0000
Subject: [issue11981] duplicated self.fp.tell() in zipfile.ZipFile.writestr
In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>
Message-ID: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>


New submission from Johan Euphrosine <proppy at google.com>:

See:
http://hg.python.org/cpython/file/2e3346fc880f/Lib/zipfile.py#l1168
http://hg.python.org/cpython/file/2e3346fc880f/Lib/zipfile.py#l1182

----------
messages: 134990
nosy: Johan.Euphrosine
priority: normal
severity: normal
status: open
title: duplicated self.fp.tell() in zipfile.ZipFile.writestr
versions: Python 3.4

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

From report at bugs.python.org  Mon May  2 18:37:17 2011
From: report at bugs.python.org (Johan Euphrosine)
Date: Mon, 02 May 2011 16:37:17 +0000
Subject: [issue11981] duplicated self.fp.tell() in zipfile.ZipFile.writestr
In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>
Message-ID: <1304354237.55.0.499998776954.issue11981@psf.upfronthosting.co.za>


Changes by Johan Euphrosine <proppy at google.com>:


----------
components: +Library (Lib)
type:  -> performance

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

From report at bugs.python.org  Mon May  2 18:51:52 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 02 May 2011 16:51:52 +0000
Subject: [issue11270] logging: RotatingFileHandler crash when opening the
	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1304355112.54.0.0689101815813.issue11270@psf.upfronthosting.co.za>


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

There is already a TimedRotatingHandler for generating file names based on dates. However, it rotates based on time, not size.

I don't agree that this is a bug just because Windows is a supported platform; the problems in this issue are due to a shortcoming in Windows. There is no universally acceptable "obvious" strategy to deal with this shortcoming. If you know of one, please elaborate.

You make no comment about my suggestion to copy files to another location before viewing.

This is not fundamentally a logging issue; any attempt to call os.rename or os.unlink will fail on Windows if the file is kept open in, say, a text editor. Logging cannot take an obvious alternative path in this case, and for that reason, IMO this issue should remain closed. 

I do not recommend raising an issue against the os module, either ;-)

----------

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

From report at bugs.python.org  Mon May  2 18:57:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 02 May 2011 16:57:56 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1303758129.61.0.483690424432.issue11849@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=mHY3ay6ZAHh0GtjM5We_8vOeenQ@mail.gmail.com>


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

I've had some time to look at this, and I've written a quick demo
patch that should - hopefully - fix this, and reduce memory
fragmentation.
 A little bit of background first:
 - a couple years ago (probably true when pymalloc was designed and
merged), glibc's malloc used brk for small and medium allocations, and
mmap for large allocations, to reduce memory fragmentation (also,
because of the processes' VM layout in older Linux 32-bit kernels, you
couldn't have a heap bigger than 1GB). The threshold for routing
requests to mmap was fixed, and had a default of 256KB (exactly the
size of an pymalloc arena). Thus, all arenas were allocated with mmap
 - in 2006, a patch was merged to make this mmap threshold dynamic,
see http://sources.redhat.com/ml/libc-alpha/2006-03/msg00033.html for
more details
 - as a consequence, with modern glibc/elibc versions, the first
arenas will be allocated through mmap, but as soon as one of them is
freed, subsequent arenas allocation will be allocated from the heap
through brk, and not mmap
 - imagine the following happens :
   1) program creates many objects
   2) to store those objects, many arenas are allocated from the heap
through brk
   3) program destroys all the objects created, except 1 which is in
the last allocated arena
   4) since the arena has at least one object in it, it's not
deallocated, and thus the heap doesn't shrink, and the memory usage
remains high (with a huge hole between the base of the heap and its
top)
 Note that 3) can be a single leaked reference, or just a variable
that doesn't get deallocated immediately. As an example, here's a demo
program that should exhibit this behaviour:

 """
 import sys
 import gc

 # allocate/de-allocate/re-allocate the array to make sure that arenas are
 # allocated through brk
 tab = []
 for i in range(1000000):
    tab.append(i)
 tab = []
 for i in range(1000000):
    tab.append(i)

 print('after allocation')
 sys.stdin.read(1)

 # allocate a dict at the top of the heap (actually it works even without) this
 a = {}

 # deallocate the big array
 del tab
 print('after deallocation')
 sys.stdin.read(1)

 # collect
 gc.collect()
 print('after collection')
 sys.stdin.read(1)
 """

 You should see that even after the big array has been deallocated and
collected, the memory usage doesn't decrease.

 Also, there's another factor coming into play, the linked list of
arenas ("arenas" variable in Object/obmalloc.c), which is expanded
when there are not enough arenas allocated: if this variable is
realloc()ed while the heap is really large and whithout hole in it, it
will be allocated from the top of the heap, and since it's not resized
when the number of used arenas goes down, it will remain at the top of
the heap and will also prevent the heap from shrinking.

 My demo patch (pymem.diff) thus does two things:
 1) use mallopt to fix the mmap threshold so that arenas are allocated
through mmap
 2) increase the maximum size of requests handled by pymalloc from
256B to 512B (as discussed above with Antoine). The reason is that if
a PyObject_Malloc request is not handled by pymalloc from an arena
(i.e. greater than 256B) and is less than the mmap threshold, then we
can't do anything if it's not freed and remains in the middle of the
heap. That's exactly what's happening in the OP case, some
dictionnaries aren't deallocated even after the collection (I couldn't
quite identify them, but there seems to be some UTF-8 codecs and other
stuff)

 To sum up, this patch increases greatly the likelihood of Python's
objects being allocated from arenas which should reduce fragmentation
(and seems to speed up certain operations quite a bit), and ensures
that arenas are allocated from mmap so that a single dangling object
doesn't prevent the heap from being trimmed.

 I've tested it on RHEL6 64-bit and Debian 32-bit, but it'd be great
if someone else could try it - and of course comment on the above
explanation/proposed solution.
Here's the result on Debian 32-bit:

Without patch:

*** Python 3.3.0 alpha
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0  1843 pts/1    S+     0:00      1  1795  9892  7528  0.5 ./python
/home/cf/issue11849_test.py
  1  1843 pts/1    S+     0:16      1  1795 63584 60928  4.7 ./python
/home/cf/issue11849_test.py
  2  1843 pts/1    S+     0:33      1  1795 112772 109064  8.4
./python /home/cf/issue11849_test.py
  3  1843 pts/1    S+     0:50      1  1795 162140 159424 12.3
./python /home/cf/issue11849_test.py
  4  1843 pts/1    S+     1:06      1  1795 211376 207608 16.0
./python /home/cf/issue11849_test.py
END  1843 pts/1    S+     1:25      1  1795 260560 256888 19.8
./python /home/cf/issue11849_test.py
 GC  1843 pts/1    S+     1:26      1  1795 207276 204932 15.8
./python /home/cf/issue11849_test.py

With patch:

*** Python 3.3.0 alpha
---   PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
  0  1996 pts/1    S+     0:00      1  1795 10160  7616  0.5 ./python
/home/cf/issue11849_test.py
  1  1996 pts/1    S+     0:16      1  1795 64168 59836  4.6 ./python
/home/cf/issue11849_test.py
  2  1996 pts/1    S+     0:33      1  1795 114160 108908  8.4
./python /home/cf/issue11849_test.py
  3  1996 pts/1    S+     0:50      1  1795 163864 157944 12.2
./python /home/cf/issue11849_test.py
  4  1996 pts/1    S+     1:07      1  1795 213848 207008 15.9
./python /home/cf/issue11849_test.py
END  1996 pts/1    S+     1:26      1  1795 68280 63776  4.9 ./python
/home/cf/issue11849_test.py
 GC  1996 pts/1    S+     1:26      1  1795 12112  9708  0.7 ./python
/home/cf/issue11849_test.py

Antoine: since the increasing of the pymalloc threshold is part of the
solution to this problem, I'm attaching a standalone patch here
(pymalloc_threshold.diff). It's included in pymem.diff.
I'll try post some pybench results tomorrow.

----------
Added file: http://bugs.python.org/file21858/pymem.diff
Added file: http://bugs.python.org/file21859/pymalloc_threshold.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11849>
_______________________________________
-------------- next part --------------
diff -r fd45c2452be3 Objects/obmalloc.c
--- a/Objects/obmalloc.c	Sat Apr 30 15:30:03 2011 +0200
+++ b/Objects/obmalloc.c	Mon May 02 18:41:41 2011 +0200
@@ -1,4 +1,5 @@
 #include "Python.h"
+#include <malloc.h>
 
 #ifdef WITH_PYMALLOC
 
@@ -75,7 +76,8 @@
  * Allocation strategy abstract:
  *
  * For small requests, the allocator sub-allocates <Big> blocks of memory.
- * Requests greater than 256 bytes are routed to the system's allocator.
+ * Requests greater than SMALL_REQUEST_THRESHOLD bytes are routed to the
+ * system's allocator.
  *
  * Small requests are grouped in size classes spaced 8 bytes apart, due
  * to the required valid alignment of the returned address. Requests of
@@ -107,10 +109,11 @@
  *       57-64                   64                       7
  *       65-72                   72                       8
  *        ...                   ...                     ...
- *      241-248                 248                      30
- *      249-256                 256                      31
+ *      497-504                 504                      62
+ *      505-512                 512                      63
  *
- *      0, 257 and up: routed to the underlying allocator.
+ *      0, SMALL_REQUEST_THRESHOLD + 1 and up: routed to the underlying
+ *      allocator.
  */
 
 /*==========================================================================*/
@@ -139,14 +142,17 @@
  * small enough in order to use preallocated memory pools. You can tune
  * this value according to your application behaviour and memory needs.
  *
+ * Note: a size threshold of 512 guarantees that newly created dictionaries
+ * will be allocated from preallocated memory pools on 64-bit.
+ *
  * The following invariants must hold:
- *      1) ALIGNMENT <= SMALL_REQUEST_THRESHOLD <= 256
+ *      1) ALIGNMENT <= SMALL_REQUEST_THRESHOLD <= 512
  *      2) SMALL_REQUEST_THRESHOLD is evenly divisible by ALIGNMENT
  *
  * Although not required, for better performance and space efficiency,
  * it is recommended that SMALL_REQUEST_THRESHOLD is set to a power of 2.
  */
-#define SMALL_REQUEST_THRESHOLD 256
+#define SMALL_REQUEST_THRESHOLD 512
 #define NB_SMALL_SIZE_CLASSES   (SMALL_REQUEST_THRESHOLD / ALIGNMENT)
 
 /*
@@ -440,6 +446,9 @@
     , PT(48), PT(49), PT(50), PT(51), PT(52), PT(53), PT(54), PT(55)
 #if NB_SMALL_SIZE_CLASSES > 56
     , PT(56), PT(57), PT(58), PT(59), PT(60), PT(61), PT(62), PT(63)
+#if NB_SMALL_SIZE_CLASSES > 64
+#error "NB_SMALL_SIZE_CLASSES should be less than 64"
+#endif /* NB_SMALL_SIZE_CLASSES > 64 */
 #endif /* NB_SMALL_SIZE_CLASSES > 56 */
 #endif /* NB_SMALL_SIZE_CLASSES > 48 */
 #endif /* NB_SMALL_SIZE_CLASSES > 40 */
@@ -545,6 +554,10 @@
         if (numarenas > PY_SIZE_MAX / sizeof(*arenas))
             return NULL;                /* overflow */
 #endif
+        /* Ensure arenas are allocated by mmap to avoid memory
+         * fragmentation. */
+        if (numarenas == INITIAL_ARENA_OBJECTS)
+            mallopt(M_MMAP_THRESHOLD, ARENA_SIZE);
         nbytes = numarenas * sizeof(*arenas);
         arenaobj = (struct arena_object *)realloc(arenas, nbytes);
         if (arenaobj == NULL)
-------------- next part --------------
diff -r bbfc65d05588 Objects/obmalloc.c
--- a/Objects/obmalloc.c	Thu Apr 07 10:48:29 2011 -0400
+++ b/Objects/obmalloc.c	Mon Apr 25 15:10:43 2011 +0200
@@ -75,7 +75,8 @@
  * Allocation strategy abstract:
  *
  * For small requests, the allocator sub-allocates <Big> blocks of memory.
- * Requests greater than 256 bytes are routed to the system's allocator.
+ * Requests greater than SMALL_REQUEST_THRESHOLD bytes are routed to the
+ * system's allocator.
  *
  * Small requests are grouped in size classes spaced 8 bytes apart, due
  * to the required valid alignment of the returned address. Requests of
@@ -107,10 +108,11 @@
  *       57-64                   64                       7
  *       65-72                   72                       8
  *        ...                   ...                     ...
- *      241-248                 248                      30
- *      249-256                 256                      31
+ *      497-504                 504                      62
+ *      505-512                 512                      63
  *
- *      0, 257 and up: routed to the underlying allocator.
+ *      0, SMALL_REQUEST_THRESHOLD + 1 and up: routed to the underlying
+ *      allocator.
  */
 
 /*==========================================================================*/
@@ -139,14 +141,17 @@
  * small enough in order to use preallocated memory pools. You can tune
  * this value according to your application behaviour and memory needs.
  *
+ * Note: a size threshold of 512 guarantees that newly created dictionaries
+ * will be allocated from preallocated memory pools on 64-bit.
+ *
  * The following invariants must hold:
- *      1) ALIGNMENT <= SMALL_REQUEST_THRESHOLD <= 256
+ *      1) ALIGNMENT <= SMALL_REQUEST_THRESHOLD <= 512
  *      2) SMALL_REQUEST_THRESHOLD is evenly divisible by ALIGNMENT
  *
  * Although not required, for better performance and space efficiency,
  * it is recommended that SMALL_REQUEST_THRESHOLD is set to a power of 2.
  */
-#define SMALL_REQUEST_THRESHOLD 256
+#define SMALL_REQUEST_THRESHOLD 512
 #define NB_SMALL_SIZE_CLASSES   (SMALL_REQUEST_THRESHOLD / ALIGNMENT)
 
 /*
@@ -440,6 +445,9 @@
     , PT(48), PT(49), PT(50), PT(51), PT(52), PT(53), PT(54), PT(55)
 #if NB_SMALL_SIZE_CLASSES > 56
     , PT(56), PT(57), PT(58), PT(59), PT(60), PT(61), PT(62), PT(63)
+#if NB_SMALL_SIZE_CLASSES > 64
+#error "NB_SMALL_SIZE_CLASSES should be less than 64"
+#endif /* NB_SMALL_SIZE_CLASSES > 64 */
 #endif /* NB_SMALL_SIZE_CLASSES > 56 */
 #endif /* NB_SMALL_SIZE_CLASSES > 48 */
 #endif /* NB_SMALL_SIZE_CLASSES > 40 */

From report at bugs.python.org  Mon May  2 19:14:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 May 2011 17:14:01 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1304356441.62.0.266428611655.issue11834@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> 
nosy: +brian.curtin, tim.golden

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

From report at bugs.python.org  Mon May  2 19:14:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 May 2011 17:14:48 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <E1QGwhr-0003sb-AZ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset db2ac3dc6cc2 by Alexander Belopolsky in branch 'default':
Issue #11930: Remove year >= 1000 limitation from datetime.strftime.
http://hg.python.org/cpython/rev/db2ac3dc6cc2

----------

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

From report at bugs.python.org  Mon May  2 19:17:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 02 May 2011 17:17:26 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <1304356646.58.0.279357281986.issue11930@psf.upfronthosting.co.za>


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


----------
components: +Extension Modules, Library (Lib)
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon May  2 19:29:55 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 02 May 2011 17:29:55 +0000
Subject: [issue11335] Memory leak after key function failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <1304357395.09.0.632743524209.issue11335@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

I checked in a fix to 3.3 just before the transition to hg.  I confess that I've been procrastinating on getting hg set up properly, which is why I haven't gotten to checking this in to 3.2.

Georg, if I get this in by Wednesday, will that be soon enough for your schedule for 3.2.1?  (it sounds like it will be)

----------
nosy: +georg.brandl
priority: normal -> release blocker

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

From report at bugs.python.org  Mon May  2 19:50:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 17:50:30 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1304358630.97.0.581714167532.issue11849@psf.upfronthosting.co.za>


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

This is a very interesting patch, thank you.
I've tested it on Mandriva 64-bit and it indeed fixes the free() issue on the XML workload. I see no regression on pybench, stringbench or json/pickle benchmarks.

I guess the final patch will have to guard the mallopt() call with some #ifdef?
(also, I suppose a portable solution would have to call mmap() ourselves for allocation of arenas, but that would probably be a bit more involved)

----------

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

From report at bugs.python.org  Mon May  2 20:15:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 May 2011 18:15:13 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <E1QGxeK-0000HJ-FL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bfd741162741 by Alexander Belopolsky in branch 'default':
Issue #11930: Added Misc/NEWS and versionchanged entries.
http://hg.python.org/cpython/rev/bfd741162741

----------

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

From report at bugs.python.org  Mon May  2 20:23:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 02 May 2011 18:23:45 +0000
Subject: [issue11962] FreeBSD-AMD64 bot sporadic hanging
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304360625.71.0.841800328938.issue11962@psf.upfronthosting.co.za>


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

Going through the logs, this indeed looks like a buildbot software
issue to me. I attach the logs that correspond to this incident:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.2/builds/85

After ...

2011-04-30 01:10:56+0200 [Broker,client]   closing stdin
2011-04-30 01:10:56+0200 [Broker,client]   using PTY: False

... normally you should see:

... [-] command finished with signal None, exit code 0, elapsedTime:


But there is nothing until I restarted the bot.

----------
Added file: http://bugs.python.org/file21860/freebsd-amd64-log.txt

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

From report at bugs.python.org  Mon May  2 21:08:27 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 May 2011 19:08:27 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304363307.77.0.416776476345.issue11888@psf.upfronthosting.co.za>


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

Here's a patch implementing log2.  Still to do:  use the system log2 where available.

----------
keywords: +patch
Added file: http://bugs.python.org/file21861/issue11888.patch

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

From report at bugs.python.org  Mon May  2 21:09:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 02 May 2011 19:09:50 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304201710.96.0.0426989644523.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110502190933.GA42748@sherwood.local>


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

On Sun,  1 May 2011 00:15:11 +0200, R. David Murray <report at bugs.python.org> wrote:
> So actually fixing this is a bit more complicated.

I like Pear OS X!
I've just tried around a bit with the other of the Pear OS
filesystems (claims to "support" two fsys: HFS+ and HFS, case
sensitive, the latter may indeed be UFS).
The following (reduced) HFS, case sensitive (UFS?) session brings
out the problem:

Access: Mon May  2 20:49:51 2011
Modify: Mon May  2 20:49:30 2011
Change: Mon May  2 20:49:50 2011
>>> os.utime('org.python', (t-3,t))
Access: Mon May  2 20:50:19 2011
Modify: Mon May  2 20:49:30 2011
Change: Mon May  2 20:50:17 2011
>>> os.utime('org.python', (t-3,t))
Access: Mon May  2 20:51:12 2011
Modify: Mon May  2 20:49:30 2011
Change: Mon May  2 20:51:11 2011

Thus the HFS, case sensitive (UFS?) implementation of f?utimes(2)
updates ctime.
It also updates atime to one+ second *after* ctime.
Well, i'm lucky it doesn't update mtime too, because ,man 2 stat`
*does* document it!!!
So, to get around yet another Pear OS X bug (unless it's really
UFS which, then, maybe has been taken as-is from FreeBSD??) i've
changed the S-Postman to do

    os.utime(self._path, (currtime, currtime+2.42))

instead, i.e. i'm using a future date.  B-/
I don't think this approach can be used by Python, however.
Non-believers:

posix.stat_result(...st_atime=1304363003, st_mtime=1304363005, st_ctime=1304363005)
>>> print(os.stat('org.python'))
posix.stat_result(...st_atime=1304363011, st_mtime=1304363005, st_ctime=1304363005)

So in fact it seems as if asynchronously the atime is updated once
again by someone, don't know who, because actually this system is
non-journaled.  Pear OS X is a Microkernel, AFAIK.

----------

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

From report at bugs.python.org  Mon May  2 21:12:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 02 May 2011 19:12:51 +0000
Subject: [issue11335] Memory leak after key function failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <1304363571.61.0.0954942447534.issue11335@psf.upfronthosting.co.za>


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

Sure, Wednesday will be fine.

----------

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

From report at bugs.python.org  Mon May  2 21:16:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 May 2011 19:16:23 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304363783.44.0.0349591875221.issue11888@psf.upfronthosting.co.za>


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

Wow Mark, that is really nice work.  Thanks.

----------

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

From report at bugs.python.org  Mon May  2 21:20:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 May 2011 19:20:42 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304364042.71.0.943054061682.issue11967@psf.upfronthosting.co.za>


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

A hint that the idea would be useful is that there is an FPU instruction, FSCALE, devoted to this.  However, a hint that this isn't needed is that Fortran and MATLAB don't have it.

----------

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

From report at bugs.python.org  Mon May  2 21:43:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 02 May 2011 19:43:25 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304365405.27.0.374885842353.issue11935@psf.upfronthosting.co.za>


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

Sorry, the last message has been truncated,
i've opened http://psf.upfronthosting.co.za/roundup/meta/issue397.
Forget the first line, but for non-believers:

PYP$ t=time.time(); os.utime('org.python', (t-2.42,t)); print(os.stat('org.python'))
posix.stat_result(...st_atime=1304363003, st_mtime=1304363005, st_ctime=1304363005)
PYP$ print(os.stat('org.python'))
posix.stat_result(...st_atime=1304363011, st_mtime=1304363005, st_ctime=1304363005)

----------
versions: +Python 3.4

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

From report at bugs.python.org  Mon May  2 21:54:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 19:54:08 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304366048.21.0.376643095778.issue9971@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon May  2 21:57:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 19:57:18 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1304366238.52.0.358105183634.issue10044@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon May  2 21:59:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 19:59:35 +0000
Subject: [issue11866] race condition in threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1304366375.48.0.0283391977475.issue11866@psf.upfronthosting.co.za>


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

Do you want to provide a patch?

----------
components: +Library (Lib) -Extension Modules
nosy: +pitrou
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Mon May  2 22:02:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 20:02:29 +0000
Subject: [issue10978] Add optional argument to Semaphore.release for releasing
	multiple threads
In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za>
Message-ID: <1304366549.03.0.663474860561.issue10978@psf.upfronthosting.co.za>


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

Your patch uses tabs for indentation. Otherwise, looks good on the principle.

----------
nosy: +pitrou
stage:  -> patch review
type: behavior -> feature request

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

From report at bugs.python.org  Mon May  2 22:05:53 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 02 May 2011 20:05:53 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1304366753.05.0.429075616323.issue6715@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Mon May  2 22:36:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 20:36:31 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1304368591.75.0.19623066494.issue1856@psf.upfronthosting.co.za>


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

With Python 3.3, thread_exit.py still crashes more or less randomly:

$ ./python thread_exit.py 
[49205 refs]
python: Python/_warnings.c:501: setup_context: Assertion `((((((PyObject*)(*filename))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed.
Abandon

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

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

From report at bugs.python.org  Mon May  2 22:37:47 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 02 May 2011 20:37:47 +0000
Subject: [issue11967] Left shift and Right shift for floats
In-Reply-To: <1304219122.96.0.441741571719.issue11967@psf.upfronthosting.co.za>
Message-ID: <1304368667.75.0.0918155405782.issue11967@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/issue11967>
_______________________________________

From report at bugs.python.org  Mon May  2 22:49:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2011 20:49:55 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1304369395.95.0.781528390361.issue1856@psf.upfronthosting.co.za>


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

A patch that seems to work under Linux and Windows (for 3.2/3.3).

----------
nosy: +haypo
stage:  -> patch review
Added file: http://bugs.python.org/file21862/finalizing.patch

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

From report at bugs.python.org  Mon May  2 23:04:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 May 2011 21:04:16 +0000
Subject: [issue11930] Remove time.accept2dyear
In-Reply-To: <1303846662.46.0.339847524577.issue11930@psf.upfronthosting.co.za>
Message-ID: <1304370256.89.0.804726388794.issue11930@psf.upfronthosting.co.za>


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

> New changeset e6f6ac8c2502 by Alexander Belopolsky in branch 'default':
> Issue #11930: Remove deprecated time.accept2dyear.

Great!

----------

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

From report at bugs.python.org  Mon May  2 23:09:02 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 02 May 2011 21:09:02 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1304370542.05.0.245927907432.issue8808@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Thanks Antoine. I've attached an updated patch. 

>> 
- the keyfile / certfile pair and the context parameter should be mutually exclusive (see e.g. the POP3_SSL constructor in Lib/poplib.py)
[Sijin] - Yes, Thanks, I don't know why I didn't check POP3 impl before.

- I don't think the remote test server used in test_imaplib supports client certificates, it probably just ignores them; that said, it's better than nothing
[Sijin] - Agreed, I don't think the server supports client certificates, but at least we are able to test that the connect still works. Maybe we should open a new task to have a remote server that supports client certificate connections? We could use that in test cases for other SSL related modules.

- you have a misindented line in test_logincapa
[Sijin] - Fixed.

- since we're using a remote, third-party test server, it may be better not to do any spurious connects (in the current patch, a first connection is established in the setUp() and then ignored since another one is established in the test body)
[Sijin] - Fixed.

- you need to update the documentation in Doc/library/imaplib.rst
[Sijin] - Done. Also added some corresponding info in the poplib and docs for poplib.

----------
Added file: http://bugs.python.org/file21863/8808.patch

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

From report at bugs.python.org  Mon May  2 23:59:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 02 May 2011 21:59:21 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1304373561.81.0.199103823851.issue11849@psf.upfronthosting.co.za>


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

> I guess the final patch will have to guard the mallopt() call with some #ifdef?

Yes. See attached patch pymalloc_frag.diff
It's the first time I'm playing with autotools, so please review this part really carefully ;-)

> (also, I suppose a portable solution would have to call mmap() ourselves
> for allocation of arenas, but that would probably be a bit more involved)

Yes. But since it probably only affects glibc/eglibc malloc versions, I guess that target implementations are likely to provide mallopt(M_MMAP_THRESHOLD).
Also, performing an anonymous mappings varies even among Unices (the mmapmodule code is scary). I'm not talking about Windows, which I don't know at all.

----------
Added file: http://bugs.python.org/file21864/pymalloc_frag.diff

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

From report at bugs.python.org  Mon May  2 23:59:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 02 May 2011 21:59:34 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1304373574.22.0.813375760846.issue11849@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21696/gc_trim.diff

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

From report at bugs.python.org  Mon May  2 23:59:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 02 May 2011 21:59:48 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1304373588.25.0.0818681544785.issue11849@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21858/pymem.diff

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

From report at bugs.python.org  Tue May  3 00:09:58 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 02 May 2011 22:09:58 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1304374198.09.0.362982458533.issue1856@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/issue1856>
_______________________________________

From report at bugs.python.org  Tue May  3 02:08:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2011 00:08:35 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304381315.78.0.0727446591342.issue8407@psf.upfronthosting.co.za>


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

> test_signal.PthreadSigmaskTests fails on Mac OS X.

The problem is that sometimes SIG_UNBLOCK does not immediatly call the pending signal, but it calls it "later". The problem is that I don't know exactly when. I tried to wait the pending signal using signal.pause(), but I got a bus error!?

Example of the problem:

pthread_sigmask(SIG_BLOCK, [SIGUSR1])
os.kill(os.getpid(), SIGUSR1)
pthread_sigmask(SIG_UNBLOCK, [SIGUSR1])

----------

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

From report at bugs.python.org  Tue May  3 02:21:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 00:21:00 +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: <1304382060.39.0.743272224243.issue6721@psf.upfronthosting.co.za>


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

I encountered this issue while debugging some multiprocessing code; fork() would be called from one thread while sys.stdout was in use in another thread (simply because of a couple of debugging statements). As a result the IO lock would be already "taken" in the child process and any operation on sys.stdout would deadlock.

This is definitely something that can happen more easily than I thought.

----------

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

From report at bugs.python.org  Tue May  3 02:57:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 00:57:20 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304384240.71.0.0334161750712.issue9205@psf.upfronthosting.co.za>


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

Here is a proof-of-concept patch that makes concurrent.futures able to detect killed processes. Works only under POSIX, and needs issue11743.
I'm not sure it's a good idea to change the multiprocessing public API (SimpleQueue.get()) for this.

----------
keywords: +patch
Added file: http://bugs.python.org/file21865/sentinels.patch

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

From report at bugs.python.org  Tue May  3 03:35:30 2011
From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=)
Date: Tue, 03 May 2011 01:35:30 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>


New submission from Manuel Cer?n <ceronman at gmail.com>:

Python 2.7.1:

>>> import json
>>> json.loads('"hello"')
u'hello'
>>> .json.loads('""')
''

Related: issue 10038

----------
components: Library (Lib)
messages: 135014
nosy: ceronman
priority: normal
severity: normal
status: open
title: json.loads() returns str instead of unicode for empty strings
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue May  3 04:11:22 2011
From: report at bugs.python.org (Eugene Toder)
Date: Tue, 03 May 2011 02:11:22 +0000
Subject: [issue11983] Inconsistent hash and comparison for code objects
In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za>
Message-ID: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za>


New submission from Eugene Toder <eltoder at gmail.com>:

A comment in the definition of PyCodeObject in Include/code.h says:

/* The rest doesn't count for hash or comparisons */

which, I think, makes a lot of sense. The implementation doesn't follow this comment, though. code_hash actually includes co_name and code_richcompare includes co_name and co_firstlineno. This makes hash and comparison inconsistent with each other and with the comment.

----------
components: Interpreter Core
messages: 135015
nosy: eltoder
priority: normal
severity: normal
status: open
title: Inconsistent hash and comparison for code objects
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May  3 05:26:03 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 May 2011 03:26:03 +0000
Subject: [issue11873] test_regexp() of test_compileall failure on "x86
	OpenIndiana 3.x"
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304393163.85.0.873467141487.issue11873@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Same here. I am using a standard ZFS configuration. If the child finish doing its job, the file should be there. Are we sure no errors happens in the child?.

----------

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

From report at bugs.python.org  Tue May  3 06:59:47 2011
From: report at bugs.python.org (Jeong-Min Lee)
Date: Tue, 03 May 2011 04:59:47 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1304398787.58.0.19162621723.issue10169@psf.upfronthosting.co.za>


Changes by Jeong-Min Lee <falsetru at gmail.com>:


----------
nosy: +falsetru

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

From report at bugs.python.org  Tue May  3 07:17:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 05:17:30 +0000
Subject: [issue11983] Inconsistent hash and comparison for code objects
In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za>
Message-ID: <1304399850.91.0.921102507962.issue11983@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May  3 08:45:53 2011
From: report at bugs.python.org (Davi Post)
Date: Tue, 03 May 2011 06:45:53 +0000
Subject: [issue11984] Wrong "See also" in symbol and token module docs
In-Reply-To: <1304405152.56.0.259676009595.issue11984@psf.upfronthosting.co.za>
Message-ID: <1304405152.56.0.259676009595.issue11984@psf.upfronthosting.co.za>


New submission from Davi Post <post at pobox.com>:

The "See also" reference in the documentation for the token and symbol modules is no longer accurate. The "second example" mentioned was apparently removed in Python 2.7.

This leaves no explanation for how to use the symbol module.

I don't think this "See also" belongs in the token module at all. (It's in Python 2.5 and 2.6 as well.)

http://docs.python.org/release/2.7.1/library/symbol.html

See also:
Module parser
    The second example for the parser module shows how to use the symbol module.

----------
assignee: docs at python
components: Documentation
messages: 135017
nosy: davipo, docs at python
priority: normal
severity: normal
status: open
title: Wrong "See also" in symbol and token module docs
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May  3 09:14:49 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 03 May 2011 07:14:49 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1304406889.29.0.382141767217.issue9516@psf.upfronthosting.co.za>


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

This issue is very annoying when you use python's with different deployment targets and should IMHO be fixed in the next release.

----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker

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

From report at bugs.python.org  Tue May  3 10:05:52 2011
From: report at bugs.python.org (Peter Saveliev)
Date: Tue, 03 May 2011 08:05:52 +0000
Subject: [issue11866] race condition in threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1304409952.5.0.465284686176.issue11866@psf.upfronthosting.co.za>


Peter Saveliev <svinota.saveliev at gmail.com> added the comment:

Ok, patch attached.

Patch made for Python: 2.6
Tested Python versions: 2.6, 2.7

----------
keywords: +patch
versions: +Python 2.6
Added file: http://bugs.python.org/file21866/newname_race_fix.patch

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

From report at bugs.python.org  Tue May  3 10:13:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 May 2011 08:13:24 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1304410404.68.0.65515971012.issue10169@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The original code was trying to call PyArg_ParseTuple assuming 2 args and in case of failure (*any* failure) was starting over assuming 3 args.
The attached patch makes PyArg_ParseTuple accept 2 or 3 args and re-arranges the last two if 'flags' is passed.
The tests pass, but a few more tests should be added.

----------
assignee:  -> ezio.melotti
keywords: +patch
nosy: +ezio.melotti
stage:  -> patch review
Added file: http://bugs.python.org/file21867/issue10169.diff

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

From report at bugs.python.org  Tue May  3 11:04:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 09:04:03 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304413443.37.0.35717273919.issue9205@psf.upfronthosting.co.za>


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

Actually, it came to me that if a child process exists, the queues are not guaranteed to be a consistent state anymore (the child could have terminated in the middle of a partial read or write). So it may be better to simply declare the ProcessPoolExecutor terminally broken when one of its children have exited.

----------

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

From report at bugs.python.org  Tue May  3 11:43:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 May 2011 09:43:03 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1304415783.55.0.0336475658195.issue10169@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Added tests and fixed all the problems they found.

----------
keywords: +needs review
stage: patch review -> commit review
Added file: http://bugs.python.org/file21868/issue10169-2.diff

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

From report at bugs.python.org  Tue May  3 12:00:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 10:00:59 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1304416859.61.0.559627075696.issue11849@psf.upfronthosting.co.za>


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

Patch looks fine to me, thank you.

----------
stage:  -> patch review
versions:  -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May  3 12:45:53 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 03 May 2011 10:45:53 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1304419553.5.0.663797354743.issue10044@psf.upfronthosting.co.za>


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

Now me.

(http://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html#Arrays-and-pointers-implementation)
> When casting from pointer to integer and back again, the resulting
> pointer must reference the same object as the original pointer,
> otherwise the behavior is undefined. That is, one may not use
> integer arithmetic to avoid the undefined behavior of pointer
> arithmetic as proscribed in C99 6.5.6/8.

Say - isn't that a joke about farts of armchair crouchers.
All it says is that if you dereference garbage you get a crash.
If you're concerned, use volatile, and go shoot the compiler
programmer if she dares to optimize just anything.
And on ARM, isn't the interrupt table at ((void*)(char[])0x0)??
La vie est une rose beside that.
And all i need is atomic_compare_and_swap().

----------
nosy: +sdaoden

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

From report at bugs.python.org  Tue May  3 13:11:25 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Tue, 03 May 2011 11:11:25 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304421085.63.0.965002749198.issue9205@psf.upfronthosting.co.za>


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

Under what circumstances do we expect a ProcessPoolExecutor child process to be killed outside of the control of the ProcessPoolExecutor?

If the user kills a child then maybe all we want to do is raise an exception rather than deadlock as a convenience.

----------

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

From report at bugs.python.org  Tue May  3 13:15:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 11:15:36 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1304421085.63.0.965002749198.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304421327.3567.1.camel@localhost.localdomain>


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

> Under what circumstances do we expect a ProcessPoolExecutor child
> process to be killed outside of the control of the
> ProcessPoolExecutor?

Killed by the user, or by an automatic device (such as the Linux OOM
killer), or crashed.

> If the user kills a child then maybe all we want to do is raise an
> exception rather than deadlock as a convenience.

That's what the patch does, roughly.

----------

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

From report at bugs.python.org  Tue May  3 13:22:48 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Tue, 03 May 2011 11:22:48 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1304421327.3567.1.camel@localhost.localdomain>
Message-ID: <8AEE276D-BC19-4B9C-BC8F-2BB6B94A0E0E@sweetapp.com>


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

> Killed by the user, or by an automatic device (such as the Linux OOM
> killer), or crashed.

Crashed would be bad - it would indicate a bug in the  
ProcessPoolExecutor code.

>
>> If the user kills a child then maybe all we want to do is raise an
>> exception rather than deadlock as a convenience.
>
> That's what the patch does, roughly.

Right. But instead of trying to recover, it might be better to fail  
very loudly i.e.
- fail every non-finished future
- kill every child process in the ProcessPoolExecutor
- set the ProcessPoolExecutor as shutdown so no new work can be  
scheduled
- raise in wait(), as_completed(), etc.

It really dependents on whether we view the situation as expected (and  
try our best to let the user recover) or as an aberrant situation that  
the user can't reasonably recover from.

Cheers,
Brian

----------

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

From report at bugs.python.org  Tue May  3 13:34:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 11:34:31 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <8AEE276D-BC19-4B9C-BC8F-2BB6B94A0E0E@sweetapp.com>
Message-ID: <1304422462.3567.3.camel@localhost.localdomain>


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

> > Killed by the user, or by an automatic device (such as the Linux OOM
> > killer), or crashed.
> 
> Crashed would be bad - it would indicate a bug in the  
> ProcessPoolExecutor code.

I meant a crash in Python itself, or any third-party extension module.

> >> If the user kills a child then maybe all we want to do is raise an
> >> exception rather than deadlock as a convenience.
> >
> > That's what the patch does, roughly.
> 
> Right. But instead of trying to recover, it might be better to fail  
> very loudly i.e.
> - fail every non-finished future
> - kill every child process in the ProcessPoolExecutor
> - set the ProcessPoolExecutor as shutdown so no new work can be  
> scheduled

Yes, I think that's better (see my message about the internal state of
queues).

----------

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

From report at bugs.python.org  Tue May  3 14:11:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 12:11:52 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QHESE-0005Gk-So@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d003ce770ba1 by Victor Stinner in branch 'default':
Issue #8407: Fix pthread_sigmask() tests on Mac OS X
http://hg.python.org/cpython/rev/d003ce770ba1

----------

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

From report at bugs.python.org  Tue May  3 14:14:40 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 03 May 2011 12:14:40 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1304347999.92.0.289179254047.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110503121427.GA20353@sherwood.local>


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

> Should we fix Python 2.7?
>  - backport issue #8651
>  - use PY_SSIZE_T_CLEAN in zlibmodule.c

I really thought about this over night.
I'm a C programmer and thus:
- Produce no bugs
- If you've produced a bug, fix it at once
- If you've fixed a bug, scream out loud "BUGFIX!" -
  or at least incorporate the patch in the very next patch release

But i have no experience with maintaining a scripting language.
My survey of something like this spans about three months now.
And if even such a heavy known bug as #1202 survives at least two
minor releases (2.6 and 2.7) without being fixed, then maybe no
more effort should be put into 2.7 at all.

> 11277-27.1.diff contains "# Issue #10276 - check that inputs
> =4GB are handled correctly.". I don't understand this comment
> because the test uses a buffer of 2 GB + 2 bytes.
> How is it possible to pass a buffer of 2 GB+2 bytes to crc32(),
> whereas it stores the size into an int. The maximum size is
> INT_MAX which is 2 GB-1 byte. It looks like the "i" format of
> PyArg_ParseTuple() doesn't check for integer overflow => issue
> #8651. This issue was fixed in 3.1, 3.2 and 3.3, but not in
> Python 2

11277-27.2.diff uses INT_MAX and thus avoids any such pitfall.
Maybe it brings up memory mapping errors somewhere which i surely
would try fix everywhere i can.

----------
Added file: http://bugs.python.org/file21869/11277-27.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -1,10 +1,16 @@
 import unittest
-from test import test_support
+from test.test_support import TESTFN, run_unittest, import_module, unlink, requires
 import binascii
 import random
 from test.test_support import precisionbigmemtest, _1G
+import sys
 
-zlib = test_support.import_module('zlib')
+try:
+    import mmap
+except ImportError:
+    mmap = None
+
+zlib = import_module('zlib')
 
 
 class ChecksumTestCase(unittest.TestCase):
@@ -66,6 +72,34 @@
                          zlib.crc32('spam',  (2**31)))
 
 
+# Backport to 2.7 due to Issue #11277: why not also verify INT32_MAX on 2.7?
+# Be aware of issues #1202, #8650, #8651 and #10276
+class ChecksumBigBufferTestCase(unittest.TestCase):
+    int_max = 0x7FFFFFFF
+
+    @unittest.skipUnless(mmap, "mmap() is not available.")
+    def test_big_buffer(self):
+        if sys.platform[:3] == 'win' or sys.platform == 'darwin':
+            requires('largefile',
+                     'test requires %s bytes and a long time to run' %
+                     str(self.int_max))
+        try:
+            with open(TESTFN, "wb+") as f:
+                f.seek(self.int_max-4)
+                f.write("asdf")
+                f.flush()
+                try:
+                    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
+                    self.assertEqual(zlib.crc32(m), 0x709418e7)
+                    self.assertEqual(zlib.adler32(m), -2072837729)
+                finally:
+                    m.close()
+        except (IOError, OverflowError):
+            raise unittest.SkipTest("filesystem doesn't have largefile support")
+        finally:
+            unlink(TESTFN)
+
+
 class ExceptionTestCase(unittest.TestCase):
     # make sure we generate some expected errors
     def test_badlevel(self):
@@ -546,8 +580,9 @@
 
 
 def test_main():
-    test_support.run_unittest(
+    run_unittest(
         ChecksumTestCase,
+        ChecksumBigBufferTestCase,
         ExceptionTestCase,
         CompressTestCase,
         CompressObjectTestCase

From report at bugs.python.org  Tue May  3 14:18:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 03 May 2011 12:18:20 +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: <1304425100.75.0.121705154381.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21855/11277-27.1.diff

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

From report at bugs.python.org  Tue May  3 14:36:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 12:36:48 +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: <E1QHEqJ-0007Kw-Qq@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 618c3e971e80 by Victor Stinner in branch '2.7':
(Merge 3.1) Issue #11277: mmap.mmap() calls fcntl(fd, F_FULLFSYNC) on Mac OS X
http://hg.python.org/cpython/rev/618c3e971e80

----------

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

From report at bugs.python.org  Tue May  3 14:57:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 12:57:20 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QHFAE-0000lT-H0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c9207c6ce24a by Victor Stinner in branch 'default':
Issue #8407: pthread_sigmask() checks immediatly if signal handlers have been
http://hg.python.org/cpython/rev/c9207c6ce24a

----------

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

From report at bugs.python.org  Tue May  3 15:08:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 13:08:14 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <E1QHFKm-0001kq-2W@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 509f1c15a1e1 by Victor Stinner in branch '2.7':
Issue #8651: Fix "z#" format of PyArg_Parse*() function: the size was not
http://hg.python.org/cpython/rev/509f1c15a1e1

----------

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

From report at bugs.python.org  Tue May  3 15:09:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 13:09:33 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <E1QHFM3-0001p3-I4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a0681e7a6ded by Victor Stinner in branch '2.7':
Issue #8651: PyArg_Parse*() functions raise an OverflowError if the file
http://hg.python.org/cpython/rev/a0681e7a6ded

----------

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

From report at bugs.python.org  Tue May  3 15:11:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2011 13:11:11 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1304428271.36.0.0846037078708.issue8651@psf.upfronthosting.co.za>


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

> Reopen the issue if you would like a port to 2.7
> (I am too lazy to do it)

I backported the fix to help issue #11277. While backporting the fix, I found another bug fixed by 509f1c15a1e1.

----------

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

From report at bugs.python.org  Tue May  3 15:19:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 13:19:37 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <E1QHFVm-0002kf-OH@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f43213129ba8 by Victor Stinner in branch '2.7':
Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
http://hg.python.org/cpython/rev/f43213129ba8

----------
nosy: +python-dev
status: pending -> open

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

From report at bugs.python.org  Tue May  3 15:23:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2011 13:23:35 +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: <1304429015.09.0.315199508785.issue11277@psf.upfronthosting.co.za>


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

I commited mmap fix for Mac OS X, crc test on 2 GB file, and issue #8651 fix into Python 2.7.

Use PY_SSIZE_T_CLEAN in zlibmodule.c is a new feature. I don't want to implement it, I don't need it, and I don't feel confortable in zlibmodule.c. Open a new issue if you want it.

I think that we are done with issue. If you see buildbots failures, reopen it.

Thanks again Steffen for your diagnosis and fixes.

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

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

From report at bugs.python.org  Tue May  3 15:29:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2011 13:29:31 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304429371.15.0.366924973954.issue8407@psf.upfronthosting.co.za>


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

Since the commit c9207c6ce24a, test_signal fails on OpenIndiana:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1179
======================================================================
ERROR: test_block_unlock (test.test_signal.PthreadSigmaskTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 539, in test_block_unlock
    self.assertEqual(set(old_mask) ^ set(blocked), {signum})
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 501, in handler
    1/0
ZeroDivisionError: division by zero

----------

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

From report at bugs.python.org  Tue May  3 15:39:06 2011
From: report at bugs.python.org (Johan Euphrosine)
Date: Tue, 03 May 2011 13:39:06 +0000
Subject: [issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr
In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>
Message-ID: <1304429946.12.0.573302737664.issue11981@psf.upfronthosting.co.za>


Changes by Johan Euphrosine <proppy at google.com>:


----------
keywords: +patch
title: duplicated self.fp.tell() in zipfile.ZipFile.writestr -> dupe self.fp.tell() in zipfile.ZipFile.writestr
Added file: http://bugs.python.org/file21870/zipfile-fix-dupe-fp-tell.patch

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

From report at bugs.python.org  Tue May  3 15:40:56 2011
From: report at bugs.python.org (Johan Euphrosine)
Date: Tue, 03 May 2011 13:40:56 +0000
Subject: [issue11980] zipfile.ZipFile.write should accept fp as argument
In-Reply-To: <1304354092.27.0.477434523561.issue11980@psf.upfronthosting.co.za>
Message-ID: <1304430056.42.0.183913331749.issue11980@psf.upfronthosting.co.za>


Johan Euphrosine <proppy at google.com> added the comment:

Here is a tentative implementation.

Feel free to review it.

----------
keywords: +patch
Added file: http://bugs.python.org/file21871/zipfile-add-writefp.patch

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

From report at bugs.python.org  Tue May  3 16:52:16 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 03 May 2011 14:52:16 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304434336.69.0.514743323755.issue11949@psf.upfronthosting.co.za>


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

> There are lots of almost-equality tests in the test-suite already,
> between test_math, test_float, test_cmath and test_complex.
>  Do you need to implement another one here, or can you reuse one
> of the existing ones?

I can probably use acc_check() instead of abs(value-expected) <= eps, but I am not sure that will be an improvement.  Most of the new logic deals with NaNs and negative zero and the almost-equality tests that I've seen don't implement these cases correctly for my use.

----------

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

From report at bugs.python.org  Tue May  3 17:21:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 15:21:00 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QHHPA-0006S5-PS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 96a532eaa2d1 by Victor Stinner in branch 'default':
Issue #8407: disable faulthandler timeout thread on all platforms
http://hg.python.org/cpython/rev/96a532eaa2d1

----------

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

From report at bugs.python.org  Tue May  3 17:25:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 15:25:47 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <E1QHHTu-0006qO-1x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset dd58f8072216 by Victor Stinner in branch '2.7':
Issue #10276: Fix test_zlib, m may be undefined in the finally block
http://hg.python.org/cpython/rev/dd58f8072216

----------

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

From report at bugs.python.org  Tue May  3 17:46:11 2011
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Tue, 03 May 2011 15:46:11 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1304437571.71.0.448949602201.issue7546@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

I got a bug report from a user that they encountered this error:

http://tahoe-lafs.org/pipermail/tahoe-dev/2011-April/006312.html

Then a follow-up in which they say they applied the patch from http://bugs.python.org/issue8597 (this ticket is the superceder of that one) and got a different error:

http://tahoe-lafs.org/pipermail/tahoe-dev/2011-April/006316.html

----------

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

From report at bugs.python.org  Tue May  3 17:54:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 May 2011 15:54:56 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304438096.8.0.481978553706.issue10496@psf.upfronthosting.co.za>


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

This is the one thing about which I wanted a call: ?after the patch, paths returned by sysconfig may not be fully expanded paths? (i.e. they may start with '~').

----------

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

From report at bugs.python.org  Tue May  3 18:05:39 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 03 May 2011 16:05:39 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304438739.13.0.39868574652.issue11949@psf.upfronthosting.co.za>


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

I was thinking of something like the rAssertAlmostEqual method in test_cmath.

----------

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

From report at bugs.python.org  Tue May  3 18:06:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 May 2011 16:06:42 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1304438802.3.0.0713101747083.issue9516@psf.upfronthosting.co.za>


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

Looks acceptable to me.  A few details in the code could be improved:

+    @unittest.skipUnless(sys.platform == 'darwin', 'MacOSX test')
Skip messages generally use another form, like ?test relevant only on Mac OS X?.

+        finally:
+            os.environ = orig_environ
I?ve grown fond of using self.addCleanup(setattr, os, 'environ', os.environ.copy()) instead of try/finally.  The cleanup action can be written right before the monkey-patching line, there?s no need to indent (especially nice when you patch many things, like later in the patch with sys.stdout), and it?s less lines.

+    def _try_compile_deployment_target(self):
+        import textwrap
I?d prefer avoiding function-level imports.

+        fp.close()
I suggest a with statement.

+        tgt = '%02d%01d0'%(tgt)
I think that using real words (?target?) and following PEP 8 (? % target?) would make this slightly more readable.

+        except CompileError:
+            self.fail("Wrong deployment target during compilation")
Why not just let the CompileError propagate and cause a unittest failure?

+        self.assertEquals(get_platform(), 'macosx-10.4-fat')
assertEquals raises a DeprecationWarning; assertEqual should be used. 
 
+
+
+
+        # Test without MACOSX_DEPLOYMENT_TARGET in the environment
+
Three blank lines, a comment line and another blank line is a lot of whitespace.

+            stderr=open('/dev/null'),
Won?t this cause a ResourceWarning?

----------
versions: +Python 3.1

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

From report at bugs.python.org  Tue May  3 18:08:10 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 03 May 2011 16:08:10 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304438890.86.0.200490593594.issue10496@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Paths that are starting with ~ should be extended with the right value with the user base. If the user base cannot be calculated, paths starting with ~ should not exist or be used at all in this context.

Maybe we need to completely reset them to None like userbase. We need to list all use cases within the stdlib and come up with a general rule.

----------

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

From report at bugs.python.org  Tue May  3 18:11:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 May 2011 16:11:09 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304439069.3.0.041789646312.issue11873@psf.upfronthosting.co.za>


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

Running test_compileall with -F it failed on iteration 588 on my linux box.  So this isn't platform specific.  No idea why that particular test should be fragile, but I'll look in to it when I get some time if nobody beats me to it.

----------
stage:  -> needs patch
title: test_regexp() of test_compileall failure on "x86 OpenIndiana 3.x" -> test_regexp() of test_compileall fails occassionally
versions: +Python 3.2

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

From report at bugs.python.org  Tue May  3 18:19:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 16:19:27 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <E1QHIJj-0003HR-Uu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f8a697bc3ca8 by Antoine Pitrou in branch 'default':
Issue #11849: Make it more likely for the system allocator to release
http://hg.python.org/cpython/rev/f8a697bc3ca8

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

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

From report at bugs.python.org  Tue May  3 18:20:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 16:20:57 +0000
Subject: [issue11849] glibc allocator doesn't release all free()ed memory
In-Reply-To: <1302858518.86.0.0355572789659.issue11849@psf.upfronthosting.co.za>
Message-ID: <1304439657.04.0.539934675989.issue11849@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/issue11849>
_______________________________________

From report at bugs.python.org  Tue May  3 18:38:06 2011
From: report at bugs.python.org (Alexandre Zani)
Date: Tue, 03 May 2011 16:38:06 +0000
Subject: [issue4851] xml.dom.minidom.Element.cloneNode fails with
	AttributeError
In-Reply-To: <1231192810.66.0.263343969898.issue4851@psf.upfronthosting.co.za>
Message-ID: <1304440686.99.0.284952386477.issue4851@psf.upfronthosting.co.za>


Changes by Alexandre Zani <alexandre.zani at gmail.com>:


----------
nosy: +Alexandre.Zani

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

From report at bugs.python.org  Tue May  3 19:04:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 May 2011 17:04:30 +0000
Subject: [issue11985] Document that platform.python_implementation supports
	PyPy
In-Reply-To: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>
Message-ID: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The docstring and reST doc of platform.python_implementation mention possible return values of CPython, IronPython and Jython, but if I understand the code correctly, PyPy is supported too.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 135050
nosy: docs at python, eric.araujo, lemburg
priority: normal
severity: normal
status: open
title: Document that platform.python_implementation supports PyPy
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May  3 19:25:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 17:25:38 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1304443538.06.0.968535174952.issue1856@psf.upfronthosting.co.za>


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

Victor pointed out that Py_Finalize() is not necessarily called in the main Python thread. This new patch records the thread state of the finalizing thread, and also includes a test case.

----------
Added file: http://bugs.python.org/file21872/finalizing2.patch

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

From report at bugs.python.org  Tue May  3 19:27:35 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 03 May 2011 17:27:35 +0000
Subject: [issue11985] Document that platform.python_implementation supports
	PyPy
In-Reply-To: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>
Message-ID: <1304443655.21.0.526488908957.issue11985@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

It returns "PyPy" on pypy.

----------
nosy: +alex

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

From report at bugs.python.org  Tue May  3 19:44:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2011 17:44:41 +0000
Subject: [issue11985] Document that platform.python_implementation supports
	PyPy
In-Reply-To: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>
Message-ID: <E1QHJeJ-0002GB-O1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f6c85df15874 by Ezio Melotti in branch '2.7':
#11985: document the return value of platform.python_implementation for PyPy.
http://hg.python.org/cpython/rev/f6c85df15874

New changeset 4d946d4166fc by Ezio Melotti in branch '3.1':
#11985: document the return value of platform.python_implementation for PyPy.
http://hg.python.org/cpython/rev/4d946d4166fc

New changeset 5e661f5c301a by Ezio Melotti in branch '3.2':
#11985: merge with 3.1.
http://hg.python.org/cpython/rev/5e661f5c301a

New changeset 847a38d787be by Ezio Melotti in branch 'default':
#11985: merge with 3.2.
http://hg.python.org/cpython/rev/847a38d787be

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

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

From report at bugs.python.org  Tue May  3 19:45:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 May 2011 17:45:55 +0000
Subject: [issue11985] Document that platform.python_implementation supports
	PyPy
In-Reply-To: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>
Message-ID: <1304444755.74.0.442562555718.issue11985@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the info!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue May  3 19:54:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 May 2011 17:54:38 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <1304445278.77.0.191323689223.issue11982@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/issue11982>
_______________________________________

From report at bugs.python.org  Tue May  3 20:22:45 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 18:22:45 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <1304446965.33.0.796642169283.issue11982@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/issue11982>
_______________________________________

From report at bugs.python.org  Tue May  3 20:31:29 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 03 May 2011 18:31:29 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> nan = float('nan')
>>> min(nan, 5)
nan
>>> min(5, nan)
5

Good arguments can be made in favor of either result, but different value for min(x, y) depending on the order of arguments can hardly be justified.

"In the face of ambiguity, refuse the temptation to guess" suggests that min/max with NaN should be an error.  See also issue 11949.

----------
messages: 135055
nosy: alex, belopolsky, durban, mark.dickinson
priority: normal
severity: normal
status: open
title: Min/max not symmetric in presence of NaN
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May  3 20:34:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 18:34:22 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1304447662.69.0.980157242515.issue11986@psf.upfronthosting.co.za>


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

Not specific to NaNs:

>>> min({1}, {2})
{1}
>>> min({2}, {1})
{2}

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

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

From report at bugs.python.org  Tue May  3 20:41:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 18:41:03 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1304448063.82.0.963023080355.issue11986@psf.upfronthosting.co.za>


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

Undefined ordering means just that.

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue May  3 20:46:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 03 May 2011 18:46:42 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304448063.82.0.963023080355.issue11986@psf.upfronthosting.co.za>
Message-ID: <BANLkTimebZg=FVsRW9R9ckfxB0BRoTqHaA@mail.gmail.com>


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

On Tue, May 3, 2011 at 2:41 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> Undefined ordering means just that.

Means what?  Compare float behavior to

Decimal('1')
>>> Decimal(1).max(Decimal('nan'))
Decimal('1')
>>> max(Decimal('1'), Decimal('nan'))
Traceback (most recent call last):
 ..
decimal.InvalidOperation: comparison involving NaN

Raymond, you don't really need to stop the debate 4 minutes after the
bug has been reported.

----------

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

From report at bugs.python.org  Tue May  3 20:58:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 18:58:04 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304449084.88.0.0608562540322.issue11949@psf.upfronthosting.co.za>


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

Alexander, I urge you to take a good deal of care with this tracker item and not make any changes lightly.  Take a look at how other languages have dealt with the issue.

Also, consider that "unorderable" may not be the right answer at all.  The most common use of NaNs is as a placeholder for missing data.  Perhaps putting them at the end of a sort is the right thing to do (c.f. was databases do with NULL values).

The other major use for NaNs is a way to let an invalid intermediate result flow through the remainder of a calculation (much as @NA does in MS Excel).  The spirit of that use case would suggest that raising an exception during a sort is the wrong thing to do.

Another consideration is that it would be unusual (and likely unexpected) to have a type be orderable or not depending on a particular value.  Users ask themselves whether floats are orderable, not whether some values of floats are orderable.

I strongly oppose this patch in its current form and think it is likely to break existing code that expects NaNs to be quiet.

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

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

From report at bugs.python.org  Tue May  3 21:00:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 19:00:04 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1304449204.49.0.638971205031.issue11949@psf.upfronthosting.co.za>


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

Also, if you're going to make a change, please consult the scipy/numpy community.  They are the most knowledgeable on the subject and the most affected by any change.

Given that they have not made any feature requests or bug reports about the current behavior, there is an indication that change isn't necessary or desirable.

----------

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

From report at bugs.python.org  Tue May  3 21:18:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 May 2011 19:18:11 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <1304450291.69.0.703579645115.issue11982@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch should fix the problem.

----------
keywords: +patch
Added file: http://bugs.python.org/file21873/issue11982.diff

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

From report at bugs.python.org  Tue May  3 21:21:14 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 19:21:14 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1304450474.02.0.0725697465187.issue11986@psf.upfronthosting.co.za>


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

The report is invalid because min/max make no guarantees about values without a total ordering.

Your other tracker item correctly focused on the behavior of float('NaN') itself, rather than on the behavior of everything else in the Python world that compares two values.

----------

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

From report at bugs.python.org  Tue May  3 21:30:08 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Tue, 03 May 2011 19:30:08 +0000
Subject: [issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
In-Reply-To: <1304451008.79.0.490801283429.issue11987@psf.upfronthosting.co.za>
Message-ID: <1304451008.79.0.490801283429.issue11987@psf.upfronthosting.co.za>


New submission from patrick vrijlandt <patrick.vrijlandt at gmail.com>:

Line 154 in standard library's queue.py, in the definition of Queue.put() is: 
self.unfinished_tasks += 1

This line should be protected by acquiring the all_tasks_done lock.
Theoretically, the increment could occur somewhere during task_done()!

Additional note:
Personally, I would like the increment to occur *before* instead of *after* _put(). This is because I would like to be able to implement a _put() that does not put everything. This put should be able to undo the increment. As it is, calling task_done() from put might decrease the counter to zero inadvertently.

----------
components: Library (Lib)
messages: 135063
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: queue.Queue.put should acquire mutex for unfinished_tasks
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue May  3 21:31:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 19:31:07 +0000
Subject: [issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
In-Reply-To: <1304451008.79.0.490801283429.issue11987@psf.upfronthosting.co.za>
Message-ID: <1304451067.59.0.371658918014.issue11987@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/issue11987>
_______________________________________

From report at bugs.python.org  Tue May  3 21:46:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 19:46:43 +0000
Subject: [issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
In-Reply-To: <1304451008.79.0.490801283429.issue11987@psf.upfronthosting.co.za>
Message-ID: <1304452003.26.0.946138390442.issue11987@psf.upfronthosting.co.za>


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

> This line should be protected by acquiring the all_tasks_done lock.

All of three of the condition variables share the same underlying lock.  The increment occurs only with the lock has been acquired. 

> Theoretically, the increment could occur somewhere during task_done()!

I don't understand what you mean.  The semantics of task_done() method implies that the count gets decremented.

> Personally, I would like the increment to occur *before* 
> instead of *after* _put().

There may be some merit to this but I don't see how it matters much since both occur within the context of the same lock being held.  A user defined method can still add or subtract any number it wants from the unfinished task count.  The result of +1 -5 is the same as -5 +1.

I'm reluctant to change the order though because the code is already published and some user's _put code may be inspecting the unfinished tasks count.  I wouldn't want to break that code without good reason.

----------

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

From report at bugs.python.org  Tue May  3 21:50:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 19:50:20 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <1304452220.89.0.959961537091.issue11982@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/issue11982>
_______________________________________

From report at bugs.python.org  Tue May  3 21:52:09 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 03 May 2011 19:52:09 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1304452329.62.0.0686544907265.issue10276@psf.upfronthosting.co.za>


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

Ha!  I always knew it!  <wink>

----------

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

From report at bugs.python.org  Tue May  3 22:38:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 20:38:13 +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: <1304455093.44.0.146586594468.issue6721@psf.upfronthosting.co.za>


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

Here is a patch with tests for the issue (some of which fail of course).
Do we agree that these tests are right?

----------
keywords: +patch
Added file: http://bugs.python.org/file21874/forklocktests.patch

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

From report at bugs.python.org  Tue May  3 22:47:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 May 2011 20:47:11 +0000
Subject: [issue11988] special method lookup docs don't address some important
	details
In-Reply-To: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>
Message-ID: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>


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

The following code:

--------------------------------
class X(list):

    def __contains__(self, key):
        print('X contains:', key)


class Y():

    def __init__(self, x):
        self.x = x

    def __getattr__(self, key):
        return getattr(self.x, key)

    def __iter__(self):
        print('Y iter')
        return iter([1,2])

x = X()
y = Y(x)

print('res:', 1 in y)
-----------------------------

prints True.  It has been explained to me that this is because of:

http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes

However, there is no way in the world that I would guess the behavior above from the documentation provided (and I find it surprising...I expected x's __contains__ to get called because Y (a class, not an instance) doesn't have a __contains__ method).

Can anyone explain it more clearly and update the documentation?

----------
assignee: docs at python
components: Documentation
messages: 135068
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: special method lookup docs don't address some important details
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May  3 22:47:34 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 03 May 2011 20:47:34 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1304455093.44.0.146586594468.issue6721@psf.upfronthosting.co.za>
Message-ID: <BANLkTinYY1oF1oB-yaZAduoGuhtV-bTmFA@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Those tests make sense to me.

----------
Added file: http://bugs.python.org/file21875/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________
-------------- next part --------------
<p>Those tests make sense to me.</p>

From report at bugs.python.org  Tue May  3 22:49:04 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 03 May 2011 20:49:04 +0000
Subject: [issue11988] special method lookup docs don't address some important
	details
In-Reply-To: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>
Message-ID: <1304455744.05.0.536445671643.issue11988@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/issue11988>
_______________________________________

From report at bugs.python.org  Tue May  3 22:56:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 May 2011 20:56:10 +0000
Subject: [issue11988] special method lookup docs don't address some important
	details
In-Reply-To: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>
Message-ID: <1304456170.46.0.709063438381.issue11988@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Tue May  3 23:00:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 May 2011 21:00:23 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1304338334.39.0.749638765621.issue8498@psf.upfronthosting.co.za>
Message-ID: <BANLkTikQ5q1KXFtvBd6o9CL+mYxVONUMXw@mail.gmail.com>


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

> To revive this issue, I tried to write a unit test to verify the behaviour.
> Onfurtunately, the test doesn't work and I don't understand why. I hope,
> someone here is more enlightend than me...

The semantic of listen's backlog argument has always been unclear, so
different implementations apply some "fudge factor" to the value
passed, see for example
http://books.google.com/books?id=ptSC4LpwGA0C&lpg=PA108&ots=Kq9FQogkTr&dq=berkeley%20listen%20backlog%20ack&pg=PA108#v=onepage&q=berkeley
listen backlog ack&f=false

Most of the time, passing <backlog> means that the kernel will queue
at least <backlog> requests.
Under the kernel I'm using (2.6.32), the maximum number of queued
requests is actually backlog + 1, and it seems to be the same on
FreeBSD (I guess one of the reason is to cope with backlog == 0).
Note that under Linux, there's another setting coming into play,
net.ipv4.tcp_abort_on_overflow:
"""
If listening service is too slow to accept new connections, reset
them. Not enabled by default. It means that if overflow occurred due
to a burst, connection will recover.
Enable this option only if you are really sure that listening daemon
cannot be tuned to accept connections faster. Enabling this option can
harm clients of your server.
"""

The goal is to avoid dropping connection requests because of a temporary burst.
So if you change your script to make as many connections as possible
with the default value, you'll probably be able to go well above
listen's backlog.
To deactivate it, you can use:
# sysctl  net.ipv4.tcp_abort_on_overflow=1

(But it's not a good idea in a production setting).

As for the test, you should add it to Lib/test/test_socket.py (just
creating a socket, binding it and passing a backlog of 0 should be
more than enough).

----------

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

From report at bugs.python.org  Tue May  3 23:17:11 2011
From: report at bugs.python.org (Chris Rose)
Date: Tue, 03 May 2011 21:17:11 +0000
Subject: [issue11970] distutils command 'upload' crashes when --show-response
	is selected
In-Reply-To: <1304257341.36.0.351902747492.issue11970@psf.upfronthosting.co.za>
Message-ID: <1304457431.31.0.845530334671.issue11970@psf.upfronthosting.co.za>


Chris Rose <offby1 at offby1.net> added the comment:

I can see that this is only an error in the 2.7.1 release, and is fixed in distutils on the 2.7 branch (along with other bugs, too, from what I can see.)

I'm closing it as invalid, given that.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue May  3 23:17:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 03 May 2011 21:17:36 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1304457456.39.0.75176465366.issue10276@psf.upfronthosting.co.za>


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

Changeset a0681e7a6ded fixes this bug for 2.7 - too-large buffers cause
an OverflowError during argument parsing, so there is no possibility of
truncation happening.

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

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

From report at bugs.python.org  Tue May  3 23:18:00 2011
From: report at bugs.python.org (Danijel)
Date: Tue, 03 May 2011 21:18:00 +0000
Subject: [issue11989] deprecate shutil.copy2
In-Reply-To: <1304457480.12.0.859066442239.issue11989@psf.upfronthosting.co.za>
Message-ID: <1304457480.12.0.859066442239.issue11989@psf.upfronthosting.co.za>


New submission from Danijel <dt at korn.shell.la>:

The function name is really ugly. The attached patch introduces an optional parameter to shutil.copy.

----------
components: Library (Lib)
files: shutil.py.diff
keywords: patch
messages: 135073
nosy: datamuc
priority: normal
severity: normal
status: open
title: deprecate shutil.copy2
type: feature request
versions: Python 3.4
Added file: http://bugs.python.org/file21876/shutil.py.diff

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

From report at bugs.python.org  Tue May  3 23:18:14 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 03 May 2011 21:18:14 +0000
Subject: [issue11988] special method lookup docs don't address some important
	details
In-Reply-To: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>
Message-ID: <1304457494.25.0.312885147039.issue11988@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

In 2.7 I get the following (if Y does not inherit from object):

>>> print('res:', 1 in y)
('X contains:', 1)
('res:', False)

This makes sense with old style classes.  With Y(object):

>>> print('res:', 1 in y)
Y iter
('res:', True)

----------
nosy: +ericsnow

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

From report at bugs.python.org  Tue May  3 23:19:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2011 21:19:20 +0000
Subject: [issue11988] special method lookup docs don't address some important
	details
In-Reply-To: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>
Message-ID: <1304457560.98.0.476720376062.issue11988@psf.upfronthosting.co.za>


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

Not sure I understand your issue here.  How should "1 in y" get at X.__contains__ given the special method lookup rules?  The __getattr__ is not called since y.__contains__ isn't looked up.

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

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

From report at bugs.python.org  Tue May  3 23:27:10 2011
From: report at bugs.python.org (James Hutchison)
Date: Tue, 03 May 2011 21:27:10 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

In windows, 64-bit, python *mostly* writes only a \n to stdout even though it's mode is 'w'. However it sometimes writes a \r\n on certain print statements and erratically when I have multiple processes writing to stdout.

Output looks fine in console, in IDLE, and using v.3.1

Example with multiple processes writing to stdout out using the same code: print("TESTCODE"); (note that in windows, the naked \n is ignored):

TESTCODETESTCODE
TESTCODE
TESTCODE
TESTCODETESTCODETESTCODE
TESTCODE

Windows program that calls python and receives its piped output is a C# .NET program.

----------
components: IO, Windows
messages: 135076
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: redirected output - stdout writes newline as \n in windows
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue May  3 23:28:04 2011
From: report at bugs.python.org (James Hutchison)
Date: Tue, 03 May 2011 21:28:04 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1304458084.65.0.0526165985105.issue11990@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

Sorry there isn't more info but I'm really busy right now

In fact a workaround would be appreciated if known.

----------

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

From report at bugs.python.org  Tue May  3 23:28:04 2011
From: report at bugs.python.org (=?utf-8?q?Piotr_Husiaty=C5=84ski?=)
Date: Tue, 03 May 2011 21:28:04 +0000
Subject: [issue11991] test_distutils fails because of bad filename match
In-Reply-To: <1304458084.66.0.88962395444.issue11991@psf.upfronthosting.co.za>
Message-ID: <1304458084.66.0.88962395444.issue11991@psf.upfronthosting.co.za>


New submission from Piotr Husiaty?ski <phusiatynski at gmail.com>:

I'm using Arch Linux, which instead of compress, provides symlink to gzip (AFAIK this will be replaced with xz). Because of that, instead of .Z extension, .gz is being used to create compressed file name.

$ ./python -m test test_distutils
[1/1] test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "/mnt/sda5/Projekty/cpython/Lib/distutils/tests/test_archive_util.py", line 165, in test_compress_deprecated
    self.assertTrue(os.path.exists(tarball))
AssertionError: False is not true

1 test failed:
    test_distutils
[1]    4874 exit 1     ./python -m test test_distutils
$ whereis compress
compress: /bin/compress /usr/share/man/man1/compress.1p.gz
$ file /bin/compress
/bin/compress: symbolic link to `gzip'

----------
assignee: tarek
components: Distutils, Tests
messages: 135077
nosy: Husio, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: test_distutils fails because of bad filename match
versions: Python 3.3

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

From report at bugs.python.org  Tue May  3 23:39:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 May 2011 21:39:57 +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: <1304458797.39.0.439682215209.issue6721@psf.upfronthosting.co.za>


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

# A lock taken from the current thread should stay taken in the
        # child process.

Note that I'm not sure of how to implement this.
After a fork, even releasing the lock can be unsafe, it must be re-initialized, see following comment in glibc's malloc implementation:
/* In NPTL, unlocking a mutex in the child process after a
   fork() is currently unsafe, whereas re-initializing it is safe and
   does not leak resources.  Therefore, a special atfork handler is
   installed for the child. */

Note that this means that even the current code allocating new locks after fork (in Lib/threading.py, _after_fork and _reset_internal_locks) is unsafe, because the old locks will be deallocated, and the lock deallocation tries to acquire and release the lock before destroying it (in issue #11148 the OP experienced a segfault on OS-X when locking a mutex, but I'm not sure of the exact context).

Also, this would imply keeping track of the thread currently owning the lock, and doesn't match the typical pthread_atfork idiom (acquire locks just before fork, release just after in parent and child, or just reinit them in the child process)

Finally, IMHO, forking while holding a lock and expecting it to be usable after fork doesn't make much sense, since a lock is acquired by a thread, and this threads doesn't exist in the child process. It's explicitely described as "undefined" by POSIX, see http://pubs.opengroup.org/onlinepubs/007908799/xsh/sem_init.html :
"""
The use of the semaphore by threads other than those created in the same process is undefined.
"""

So I'm not sure whether it's feasable/wise to provide such a guarantee.

----------

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

From report at bugs.python.org  Tue May  3 23:43:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 May 2011 21:43:41 +0000
Subject: [issue11988] special method lookup docs don't address some important
	details
In-Reply-To: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>
Message-ID: <1304459021.78.0.854822828688.issue11988@psf.upfronthosting.co.za>


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

Well, then I suppose my question is why isn't __contains__ looked up?  Other special methods that don't exist on Y do cause __getattr__ to be called.  Why is __contains__ special?  The docs for __getattr__ don't hint at this possibility either.

I think the people that understand this must have a mental model of how the interpreter looks up methods that has some pieces that are missing from mine.  I guess I'd like those bits to be made explicit in the special method lookup docs, or if they are already documented somewhere, for there to be a pointer to them in the special method lookup docs.

----------

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

From report at bugs.python.org  Tue May  3 23:52:10 2011
From: report at bugs.python.org (James Hutchison)
Date: Tue, 03 May 2011 21:52:10 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1304459530.06.0.267025356784.issue11990@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

Nevermind, I have a workaround that didn't require rewriting all the print statements but its in the C# code not the python code

----------

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

From report at bugs.python.org  Wed May  4 00:01:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 May 2011 22:01:56 +0000
Subject: [issue11988] special method lookup docs don't address some important
	details
In-Reply-To: <1304455631.01.0.264040156642.issue11988@psf.upfronthosting.co.za>
Message-ID: <1304460116.34.0.354800871369.issue11988@psf.upfronthosting.co.za>


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

Ah, that's what my problem is.  My test example was poorly conceived (I used __del__!) so I *thought* the other special methods were triggering getattr.

I'd have figured it out if I hadn't screwed up my test :(

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

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

From report at bugs.python.org  Wed May  4 00:05:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2011 22:05:37 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1304458797.39.0.439682215209.issue6721@psf.upfronthosting.co.za>
Message-ID: <1304460331.3567.18.camel@localhost.localdomain>


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

> Also, this would imply keeping track of the thread currently owning
> the lock,

Yes, we would need to keep track of the thread id and process id inside
the lock. We also need a global variable of the main thread id after
fork, and a per-lock "taken" flag.

Synopsis:

    def _reinit_if_needed(self):
        # Call this before each acquire() or release()
        if self.pid != getpid():
            sem_init(self.sem, 0, 1)
            if self.taken:
                if self.tid == main_thread_id_after_fork:
                    # Lock was taken in forked thread, re-take it
                    sem_wait(self.sem)
                else:
                    # It's now released
                    self.taken = False
            self.pid = getpid()
            self.tid = current_thread_id()

> and doesn't match the typical pthread_atfork idiom (acquire locks just
> before fork, release just after in parent and child, or just reinit
> them in the child process)

Well, I fail to understand how that idiom can help us. We're not a
self-contained application, we're a whole programming language.
Calling fork() only when no lock is held is unworkable (for example, we
use locks around buffered I/O objects).

----------

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

From report at bugs.python.org  Wed May  4 00:15:41 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 03 May 2011 22:15:41 +0000
Subject: [issue11962] Buildbot reliability
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304460941.94.0.170252818098.issue11962@psf.upfronthosting.co.za>


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

Another instance:

2011-05-03 20:18:08+0200 [Broker,client]   closing stdin
2011-05-03 20:18:08+0200 [Broker,client]   using PTY: False
2011-05-03 20:20:38+0200 [-] sending app-level keepalive


Again this is missing:

... [-] command finished with signal None, exit code 0, elapsedTime:


Also, as we speak the Ubuntu PPC bot is hanging as well:


http://www.python.org/dev/buildbot/all/builders/PPC%20Ubuntu%202.7/builds/386/steps/test/logs/stdio



Antoine, do you have access to the server logs for the relevant
times? My bot is on CEST.

----------
title: FreeBSD-AMD64 bot sporadic hanging -> Buildbot reliability

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

From report at bugs.python.org  Wed May  4 00:17:09 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 03 May 2011 22:17:09 +0000
Subject: [issue11962] Buildbot reliability
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304461029.44.0.479757556172.issue11962@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Wed May  4 00:40:59 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 May 2011 22:40:59 +0000
Subject: [issue11962] Buildbot reliability
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304462459.51.0.281781773092.issue11962@psf.upfronthosting.co.za>


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

My Ubuntu PPC server is having hardware problems.  It will just intermittently shut off.  I've reset the SMU and the PRAM, vacuumed out the guts, reseated the RAM, pulled any possibly problematic 3rd party boards, and it still crashes.  I was watching the syslog and it didn't look like a thermal shutdown, though it acted like that.  The only thing I can think of is a power supply problem, so I'm going to see if I can find an inexpensive replacement.  In the meantime, this machine will be offline for a couple of weeks at least.

----------

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

From report at bugs.python.org  Wed May  4 00:47:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 03 May 2011 22:47:45 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1304462865.72.0.556659520234.issue7546@psf.upfronthosting.co.za>


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

The poster should get the same error messages from:

ml64 /c /Cx x64dll.asm


Perhaps the assembly isn't MASM?

----------

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

From report at bugs.python.org  Wed May  4 01:53:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2011 23:53:08 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1304429371.15.0.366924973954.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304466779.14458.12.camel@marge>


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

> Since the commit c9207c6ce24a, test_signal fails on OpenIndiana:
> 
> http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1179
> ======================================================================
> ERROR: test_block_unlock (test.test_signal.PthreadSigmaskTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 539, in test_block_unlock
>     self.assertEqual(set(old_mask) ^ set(blocked), {signum})
>   File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 501, in handler
>     1/0
> ZeroDivisionError: division by zero

This is because a thread different than the main thread receives the
signal and calls the signal handler. Antoine found that "python -m
test_pydoc test_signal" is enough to reproduce the problem (on any OS,
or at least on Linux). test_pydoc loads a lot (all?) of Python modules
including _tkinter, and _tkinter (libtcl) creates a C thread which waits
events using select().

I see 3 solutions:

a) Use pthread_kill() to send the signal directly to the right thread
(the main thread)

b) Destroy _tkinter: Tcl_Finalize() exits the thread, but this function
is never called. _tkinter.c contains the following code:
#if 0
    /* This was not a good idea; through <Destroy> bindings,
       Tcl_Finalize() may invoke Python code but at that point the
       interpreter and thread state have already been destroyed! */
    Py_AtExit(Tcl_Finalize);
#endif

c) Skip the test if the _tkinter thread is present. Check if the
_tkinter module is loaded *should* be enough to check if the Tcl thread
is running. Unload the _tkinter module is not possible: modules written
in C cannot be unloaded. But it is possible to remove all references
from the Python object space, so check >'_tkinter' in sys.modules< is
maybe not reliable.

I don't know if some platforms have pthread_sigmask() but not
pthread_kill().

I have a patch to expose pthread_kill(), sigpending() and sigwait(). I
will publish it tomorrow for a review.

--

test_signal doesn't fail on all platforms. Possible reasons:

 - the platform doesn't have pthread_sigmask(), and so the test is
skipped
 - the libtcl version is different, a newer version masks maybe signals?
 - (unlikely!) os.kill() always sends the signal to the main thread

----------

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

From report at bugs.python.org  Wed May  4 02:01:30 2011
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Wed, 04 May 2011 00:01:30 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1304467290.56.0.458331462269.issue7546@psf.upfronthosting.co.za>


Zooko O'Whielacronx <zooko at zooko.com> added the comment:

Thanks, Stefan Krah. I posted your comment to the tahoe-dev mailing list:

http://tahoe-lafs.org/pipermail/tahoe-dev/2011-May/006336.html

Also Samuel Neves has posted on that thread.

----------

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

From report at bugs.python.org  Wed May  4 03:58:53 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 04 May 2011 01:58:53 +0000
Subject: [issue11992] sys.settrace doesn't disable tracing if a local trace
	function returns None
In-Reply-To: <1304474333.76.0.969797512596.issue11992@psf.upfronthosting.co.za>
Message-ID: <1304474333.76.0.969797512596.issue11992@psf.upfronthosting.co.za>


New submission from Ned Batchelder <nedbat at users.sourceforge.net>:

The docs say:

    The trace function is invoked (with event set to 'call') whenever a new local scope is entered; it should return a reference to a local trace function to be used that scope, or None if the scope shouldn?t be traced.

    The local trace function should return a reference to itself (or to another function for further tracing in that scope), or None to turn off tracing in that scope.

It's that last part that's wrong: returning None from the trace function only has an effect on the first call in a new frame.  Once the trace function returns a function for a frame, returning None from subsequent calls is ignored.  A "local trace function" can't turn off tracing in its scope.

To demonstrate:

    import sys

    UPTO_LINE = 1

    def t(frame, event, arg):
        num = frame.f_lineno
        print("line %d" % num)
        if num < UPTO_LINE:
            return t

    def try_it():
        print("twelve")
        print("thirteen")
        print("fourteen")
        print("fifteen")

    UPTO_LINE = 1
    sys.settrace(t)
    try_it()

    UPTO_LINE = 13
    sys.settrace(t)
    try_it()

Produces:

    line 11
    twelve
    thirteen
    fourteen
    fifteen
    line 11
    line 12
    twelve
    line 13
    thirteen
    line 14
    fourteen
    line 15
    fifteen
    line 15

The first call to try_it() returns None immediately, preventing tracing for the rest of the function.  The second call returns None at line 13, but the rest of the function is traced anyway.  This behavior is the same in all versions from 2.3 to 3.2, in fact, the 100 lines of code in sysmodule.c responsible for Python tracing functions are completely unchanged through those versions.

----------
components: Library (Lib)
messages: 135089
nosy: nedbat
priority: normal
severity: normal
status: open
title: sys.settrace doesn't disable tracing if a local trace function returns None
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed May  4 04:03:44 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 04 May 2011 02:03:44 +0000
Subject: [issue11992] sys.settrace doesn't disable tracing if a local trace
	function returns None
In-Reply-To: <1304474333.76.0.969797512596.issue11992@psf.upfronthosting.co.za>
Message-ID: <1304474624.67.0.433634416807.issue11992@psf.upfronthosting.co.za>


Changes by Ned Batchelder <nedbat at users.sourceforge.net>:


----------
assignee:  -> nedbat

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

From report at bugs.python.org  Wed May  4 04:23:52 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 04 May 2011 02:23:52 +0000
Subject: [issue11993] Is it desired to distinguish new files from old with
	sub-second resolution?
In-Reply-To: <1304475832.41.0.871788475686.issue11993@psf.upfronthosting.co.za>
Message-ID: <1304475832.41.0.871788475686.issue11993@psf.upfronthosting.co.za>


New submission from John S. Gruber <johnsgruber at gmail.com>:

This report is meant to prompt discussion, if desired, on the advisability of distinguishing new files from old using subsecond data. (It isn't clear to me that it is important to do this.)

Some file systems keep sub-second modification times, but the number of seconds since the epoch grows to a very large number, and given the limited number of significant bits in floating point numbers, it's important to carry out this comparison carefully (or use some new integer data) so newly created files don't appear to be older than their source files due to rounding and other conversion anomalies. Current floats don't have the precision to hold both the number of seconds since the epoch and a nanosecond precision fractional second.

----------
assignee: tarek
components: Distutils2
messages: 135090
nosy: alexis, eric.araujo, jsjgruber, tarek
priority: normal
severity: normal
status: open
title: Is it desired to distinguish new files from old with sub-second resolution?
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Wed May  4 04:42:37 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 04 May 2011 02:42:37 +0000
Subject: [issue11993] Is it desired to distinguish new files from old with
	sub-second resolution?
In-Reply-To: <1304475832.41.0.871788475686.issue11993@psf.upfronthosting.co.za>
Message-ID: <1304476957.9.0.690572462833.issue11993@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Is this proposing some sort of change or problem?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Wed May  4 05:00:24 2011
From: report at bugs.python.org (John S. Gruber)
Date: Wed, 04 May 2011 03:00:24 +0000
Subject: [issue11993] Is it desired to distinguish new files from old with
	sub-second resolution?
In-Reply-To: <1304475832.41.0.871788475686.issue11993@psf.upfronthosting.co.za>
Message-ID: <1304478024.89.0.54500681459.issue11993@psf.upfronthosting.co.za>


John S. Gruber <johnsgruber at gmail.com> added the comment:

Thanks for writing so quickly.

This topic arose as part of issue 11933 (similar number).  ?ric Araujo asked that I bring this up in either mail to the fellowship of the packaging or as a separate bug report, so I chose to file this. Please see msg 134634 from that issue. I suppose ?ric may believe sub-second time comparison is a possibility for distutils2. I think *if* it is done the integer/float conversion implication should be considered, given my limited experience with the topic in distutils.i

Thanks again.

----------

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

From report at bugs.python.org  Wed May  4 05:02:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 03:02:21 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <E1QHSLw-00014n-JK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 175dcc8c4b23 by Brian Curtin in branch '3.1':
Fix #11834. Correct site-packages paths.
http://hg.python.org/cpython/rev/175dcc8c4b23

New changeset 03d511dec224 by Brian Curtin in branch '3.2':
Fix #11834. Correct site-packages paths.
http://hg.python.org/cpython/rev/03d511dec224

New changeset 066e63425228 by Brian Curtin in branch 'default':
Fix #11834. Correct site-packages paths.
http://hg.python.org/cpython/rev/066e63425228

New changeset 1a2f0f545f55 by Brian Curtin in branch '2.7':
Fix #11834. Correct site-packages paths.
http://hg.python.org/cpython/rev/1a2f0f545f55

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

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

From report at bugs.python.org  Wed May  4 05:03:57 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 04 May 2011 03:03:57 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1304478237.54.0.679694888032.issue11834@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Thanks for the patches and reviews!

----------
assignee:  -> brian.curtin
resolution:  -> fixed
stage: needs patch -> committed/rejected
type:  -> behavior

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

From report at bugs.python.org  Wed May  4 07:56:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 04 May 2011 05:56:19 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1304460331.3567.18.camel@localhost.localdomain>
Message-ID: <BANLkTikzeM_Y5xodqeDUbOBuJ3qQU4hOnA@mail.gmail.com>


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

> Yes, we would need to keep track of the thread id and process id inside
> the lock. We also need a global variable of the main thread id after
> fork, and a per-lock "taken" flag.
>
> Synopsis:
>
> ? ?def _reinit_if_needed(self):
> ? ? ? ?# Call this before each acquire() or release()
> ? ? ? ?if self.pid != getpid():
> ? ? ? ? ? ?sem_init(self.sem, 0, 1)
> ? ? ? ? ? ?if self.taken:
> ? ? ? ? ? ? ? ?if self.tid == main_thread_id_after_fork:
> ? ? ? ? ? ? ? ? ? ?# Lock was taken in forked thread, re-take it
> ? ? ? ? ? ? ? ? ? ?sem_wait(self.sem)
> ? ? ? ? ? ? ? ?else:
> ? ? ? ? ? ? ? ? ? ?# It's now released
> ? ? ? ? ? ? ? ? ? ?self.taken = False
> ? ? ? ? ? ?self.pid = getpid()
> ? ? ? ? ? ?self.tid = current_thread_id()
>

A couple remarks:
- with linuxthreads, different threads within the same process have
the same PID - it may be true for other implementations - so this
would lead to spurious reinitializations
- what's current_thread_id ? If it's thread_get_ident (pthread_self),
since TID is not guaranteed to be inherited across fork, this won't
work
- calling getpid at every acquire/release is expensive, even though
it's a trivial syscall (it'll have to measured though)
- imagine the following happens:

P1

lock.acquire()
fork()    ->       P2
                       start_new_thread T2
                       T1           T2
                                        lock.acquire()

The acquisition of lock by T2 will cause lock's reinitialization: what
happens to the lock wait queue ? who owns the lock ?
That why I don't think we can delay the reinitialization of locks, but
I could be wrong.

> Well, I fail to understand how that idiom can help us. We're not a
> self-contained application, we're a whole programming language.
> Calling fork() only when no lock is held is unworkable (for example, we
> use locks around buffered I/O objects).

Yes, but in that case, you don't have to reacquire the locks after fork.
In the deadlock you experienced above, the thread that forked wasn't
the one in the I/O code, so the corresponding lock can be
re-initialized anyway, since the thread in the I/O code at that time
won't exist after fork.
And it's true with every lock in the library code: they're only held
in short critical sections (typically acquired when entering a
function and released when leaving), and since it's not the threads
inside those libraries that fork, all those locks can simply be
reinitialized on fork, without having the reacquire them.

----------

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

From report at bugs.python.org  Wed May  4 08:01:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 04 May 2011 06:01:01 +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: <1304488861.63.0.288312460197.issue6721@psf.upfronthosting.co.za>


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

Oops, for liunxthreads, you should of course read "different PIDs", not "same PID".

----------

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

From report at bugs.python.org  Wed May  4 08:09:23 2011
From: report at bugs.python.org (patrick vrijlandt)
Date: Wed, 04 May 2011 06:09:23 +0000
Subject: [issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
In-Reply-To: <1304452003.26.0.946138390442.issue11987@psf.upfronthosting.co.za>
Message-ID: <BANLkTincdCu_6twEfxuwv95MtM9xZ946CA@mail.gmail.com>


patrick vrijlandt <patrick.vrijlandt at gmail.com> added the comment:

I agree. Please close the ticket.

Thanks,

Patrick

2011/5/3 Raymond Hettinger <report at bugs.python.org>

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> > This line should be protected by acquiring the all_tasks_done lock.
>
> All of three of the condition variables share the same underlying lock.
>  The increment occurs only with the lock has been acquired.
>
> > Theoretically, the increment could occur somewhere during task_done()!
>
> I don't understand what you mean.  The semantics of task_done() method
> implies that the count gets decremented.
>
> > Personally, I would like the increment to occur *before*
> > instead of *after* _put().
>
> There may be some merit to this but I don't see how it matters much since
> both occur within the context of the same lock being held.  A user defined
> method can still add or subtract any number it wants from the unfinished
> task count.  The result of +1 -5 is the same as -5 +1.
>
> I'm reluctant to change the order though because the code is already
> published and some user's _put code may be inspecting the unfinished tasks
> count.  I wouldn't want to break that code without good reason.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11987>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file21877/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11987>
_______________________________________
-------------- next part --------------
I agree. Please close the ticket.<div><br></div><div>Thanks,</div><div><br></div><div>Patrick<br><br><div class="gmail_quote">2011/5/3 Raymond Hettinger <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>
Raymond Hettinger &lt;<a href="mailto:raymond.hettinger at gmail.com">raymond.hettinger at gmail.com</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; This line should be protected by acquiring the all_tasks_done lock.<br>
<br>
</div>All of three of the condition variables share the same underlying lock. ??The increment occurs only with the lock has been acquired.<br>
<div class="im"><br>
&gt; Theoretically, the increment could occur somewhere during task_done()!<br>
<br>
</div>I don&#39;t understand what you mean. ??The semantics of task_done() method implies that the count gets decremented.<br>
<div class="im"><br>
&gt; Personally, I would like the increment to occur *before*<br>
&gt; instead of *after* _put().<br>
<br>
</div>There may be some merit to this but I don&#39;t see how it matters much since both occur within the context of the same lock being held. ??A user defined method can still add or subtract any number it wants from the unfinished task count. ??The result of +1 -5 is the same as -5 +1.<br>

<br>
I&#39;m reluctant to change the order though because the code is already published and some user&#39;s _put code may be inspecting the unfinished tasks count. ??I wouldn&#39;t want to break that code without good reason.<br>

<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue11987" target="_blank">http://bugs.python.org/issue11987</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Wed May  4 08:14:09 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 May 2011 06:14:09 +0000
Subject: [issue11987] queue.Queue.put should acquire mutex for unfinished_tasks
In-Reply-To: <1304451008.79.0.490801283429.issue11987@psf.upfronthosting.co.za>
Message-ID: <1304489649.04.0.0529543899991.issue11987@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed May  4 08:21:23 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 04 May 2011 06:21:23 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>


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

I can reproduce this only with gcc-4.4.3, so it could also be
a compiler bug. Also, the segfault only occurs when python is
compiled with optimizations and run under valgrind.


hg up 2.7
make distclean
./configure
make
valgrind --suppressions=Misc/valgrind-python.supp ./python
>>> s = "-- -- --"
>>> s.split('--')
==29273== Invalid read of size 4
==29273==    at 0x456C73: PyObject_Free (obmalloc.c:969)
==29273==    by 0x4AD3BD: compiler_unit_free (compile.c:424)
==29273==    by 0x4B6785: compiler_mod (compile.c:521)
==29273==    by 0x4B69B5: PyAST_Compile (compile.c:289)
==29273==    by 0x4CD564: PyRun_InteractiveOneFlags (pythonrun.c:1343)
==29273==    by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765)
==29273==    by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734)
==29273==    by 0x4172E9: Py_Main (main.c:599)
==29273==    by 0x56F2C4C: (below main) (libc-start.c:226)
==29273==  Address 0x61d3020 is not stack'd, malloc'd or (recently) free'd
==29273== 
==29273== Invalid read of size 4
==29273==    at 0x456C73: PyObject_Free (obmalloc.c:969)
==29273==    by 0x4B6785: compiler_mod (compile.c:521)
==29273==    by 0x4B69B5: PyAST_Compile (compile.c:289)
==29273==    by 0x4CD564: PyRun_InteractiveOneFlags (pythonrun.c:1343)
==29273==    by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765)
==29273==    by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734)
==29273==    by 0x4172E9: Py_Main (main.c:599)
==29273==    by 0x56F2C4C: (below main) (libc-start.c:226)
==29273==  Address 0x61d3020 is not stack'd, malloc'd or (recently) free'd
==29273== 
==29273== Invalid read of size 8
==29273==    at 0x43E5A8: list_print (listobject.c:341)
==29273==    by 0x454CAF: internal_print (object.c:315)
==29273==    by 0x432128: PyFile_WriteObject (fileobject.c:110)
==29273==    by 0x4D3857: sys_displayhook (sysmodule.c:115)
==29273==    by 0x41BD66: PyObject_Call (abstract.c:2529)
==29273==    by 0x4A4CB2: PyEval_CallObjectWithKeywords (ceval.c:3882)
==29273==    by 0x4AA568: PyEval_EvalFrameEx (ceval.c:1739)
==29273==    by 0x4ACE90: PyEval_EvalCodeEx (ceval.c:3253)
==29273==    by 0x4ACFA1: PyEval_EvalCode (ceval.c:667)
==29273==    by 0x4CD57E: PyRun_InteractiveOneFlags (pythonrun.c:1346)
==29273==    by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765)
==29273==    by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734)
==29273==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==29273== 
==29273== 
==29273== Process terminating with default action of signal 11 (SIGSEGV)
==29273==  Access not within mapped region at address 0x0
==29273==    at 0x43E5A8: list_print (listobject.c:341)
==29273==    by 0x454CAF: internal_print (object.c:315)
==29273==    by 0x432128: PyFile_WriteObject (fileobject.c:110)
==29273==    by 0x4D3857: sys_displayhook (sysmodule.c:115)
==29273==    by 0x41BD66: PyObject_Call (abstract.c:2529)
==29273==    by 0x4A4CB2: PyEval_CallObjectWithKeywords (ceval.c:3882)
==29273==    by 0x4AA568: PyEval_EvalFrameEx (ceval.c:1739)
==29273==    by 0x4ACE90: PyEval_EvalCodeEx (ceval.c:3253)
==29273==    by 0x4ACFA1: PyEval_EvalCode (ceval.c:667)
==29273==    by 0x4CD57E: PyRun_InteractiveOneFlags (pythonrun.c:1346)
==29273==    by 0x4CD80D: PyRun_InteractiveLoopFlags (pythonrun.c:765)
==29273==    by 0x4CDFFA: PyRun_AnyFileExFlags (pythonrun.c:734)
==29273==  If you believe this happened as a result of a stack
==29273==  overflow in your program's main thread (unlikely but
==29273==  possible), you can try to increase the size of the
==29273==  main thread stack using the --main-stacksize= flag.
==29273==  The main thread stack size used in this run was 8388608.
[''==29273== 
==29273== HEAP SUMMARY:
==29273==     in use at exit: 2,198,606 bytes in 1,256 blocks
==29273==   total heap usage: 7,315 allocs, 6,059 frees, 7,364,086 bytes allocated
==29273== 
==29273== LEAK SUMMARY:
==29273==    definitely lost: 0 bytes in 0 blocks
==29273==    indirectly lost: 0 bytes in 0 blocks
==29273==      possibly lost: 641,033 bytes in 353 blocks
==29273==    still reachable: 1,557,541 bytes in 902 blocks
==29273==         suppressed: 32 bytes in 1 blocks
==29273== Rerun with --leak-check=full to see details of leaked memory
==29273== 
==29273== For counts of detected and suppressed errors, rerun with: -v
==29273== Use --track-origins=yes to see where uninitialised values come from
==29273== ERROR SUMMARY: 416 errors from 28 contexts (suppressed: 13 from 7)
Segmentation fault

----------
components: Interpreter Core
messages: 135098
nosy: skrah
priority: normal
severity: normal
status: open
title: [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed May  4 09:04:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 07:04:31 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304492671.16.0.15826240152.issue11994@psf.upfronthosting.co.za>


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

> I can reproduce this only with gcc-4.4.3, so it could also be a compiler bug.

You should try to disable compiler optimization: pass -O0 to gcc. E.g. use ./configure --with-pydebug CFLAGS="-O0".

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

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

From report at bugs.python.org  Wed May  4 09:18:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 07:18:08 +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: <1304493488.56.0.46575265613.issue6721@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/issue6721>
_______________________________________

From report at bugs.python.org  Wed May  4 10:29:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 08:29:27 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>


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

PydocUrlHandlerTest.test_url_requests() of test_doc checks "search?key=pydoc" URL. This operation has to load all Python modules to get their documentation. The problem is that loading all modules can have border effects with other tests. The most recent example: test_signal fails if it runs after test_pydoc. test_pydoc imports _tkinter and _tkinter loads the Tcl library which creates a thread waiting events in select(). The problem is that test_signal supposes that there is only one running thread.

Can we run tests loading all modules in a subprocess?

I have a fix to test_signal, so this bug is not really blocker, but it's better if a test doesn't touch the environment too much.

---

To see which modules are imported by pydoc, you can use:
import pydoc; pydoc.ModuleScanner().run(lambda *args: 0, 'XXX')

Result on my host (using python -v):

__future__
_ast
_bz2
_compat_pickle
_ctypes
_curses
_datetime
_hashlib
_json
_multiprocessing
_pickle
_posixsubprocess
_random
_socket
_sqlite3
_struct
_symtable
_tkinter
array
atexit
bdb
binascii
bz2
cmd
code
codeop
concurrent
concurrent
concurrent.futures
concurrent.futures
concurrent.futures._base
concurrent.futures.process
concurrent.futures.thread
contextlib
copy
ctypes
ctypes
ctypes._endian
ctypes.macholib
ctypes.macholib
ctypes.test
ctypes.test
curses
curses
curses.wrapper
datetime
dbm
dbm
difflib
distutils
distutils
distutils.command
distutils.command
distutils.tests
distutils.tests
doctest
email
email
email.mime
email.mime
encodings.cp1252
encodings.idna
encodings.koi8_r
faulthandler
fcntl
fnmatch
gc
getopt
gettext
grp
hashlib
html
html
http
http
idlelib
idlelib
importlib
importlib
importlib._bootstrap
importlib.test
importlib.test
importlib.test.builtin
importlib.test.builtin
importlib.test.extension
importlib.test.extension
importlib.test.frozen
importlib.test.frozen
importlib.test.import_
importlib.test.import_
importlib.test.source
importlib.test.source
json
json
json.decoder
json.encoder
json.scanner
lib2to3
lib2to3
lib2to3.btm_matcher
lib2to3.btm_utils
lib2to3.fixer_base
lib2to3.fixer_util
lib2to3.fixes
lib2to3.fixes
lib2to3.fixes.fix_imports
lib2to3.fixes.fix_imports2
lib2to3.fixes.fix_urllib
lib2to3.main
lib2to3.patcomp
lib2to3.pgen2
lib2to3.pgen2
lib2to3.pgen2.driver
lib2to3.pgen2.grammar
lib2to3.pgen2.literals
lib2to3.pgen2.parse
lib2to3.pgen2.pgen
lib2to3.pgen2.token
lib2to3.pgen2.tokenize
lib2to3.pygram
lib2to3.pytree
lib2to3.refactor
lib2to3.tests
lib2to3.tests
lib2to3.tests.support
lib2to3.tests.test_all_fixers
lib2to3.tests.test_fixers
lib2to3.tests.test_main
lib2to3.tests.test_parser
lib2to3.tests.test_pytree
lib2to3.tests.test_refactor
lib2to3.tests.test_util
logging
logging
logging.handlers
marshal
math
msilib
msilib
multiprocessing
multiprocessing
multiprocessing.dummy
multiprocessing.dummy
multiprocessing.dummy.connection
multiprocessing.forking
multiprocessing.process
multiprocessing.queues
multiprocessing.synchronize
multiprocessing.util
myfixes
myfixes
optparse
pdb
pickle
pprint
pwd
pydoc_data
pydoc_data
queue
random
select
shutil
socket
sqlite3
sqlite3
sqlite3.dbapi2
sqlite3.test
sqlite3.test
stringprep
struct
subprocess
tarfile
tempfile
test
test
test.encoded_modules
test.encoded_modules
test.json_tests
test.json_tests
test.leakers
test.leakers
test.support
test.test_email
test.test_email
test.tracedmodules
test.tracedmodules
textwrap
threading
tkinter
tkinter
tkinter.constants
tkinter.test
tkinter.test
tkinter.test.test_tkinter
tkinter.test.test_tkinter
tkinter.test.test_ttk
tkinter.test.test_ttk
turtledemo
turtledemo
unicodedata
unittest
unittest
unittest.case
unittest.loader
unittest.main
unittest.result
unittest.runner
unittest.signals
unittest.suite
unittest.test
unittest.test
unittest.util
urllib
urllib
wsgiref
wsgiref
xml
xml
xml.dom
xml.dom
xml.dom.domreg
xml.dom.minicompat
xml.etree
xml.etree
xml.parsers
xml.parsers
xml.sax
xml.sax
xml.sax._exceptions
xml.sax.handler
xml.sax.xmlreader
xmlrpc
xmlrpc
xxsubtype

----------
components: Tests
messages: 135100
nosy: haypo
priority: normal
severity: normal
status: open
title: test_pydoc loads all Python modules
versions: Python 3.3

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

From report at bugs.python.org  Wed May  4 10:43:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 08:43:59 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1304498639.73.0.390541662234.issue11995@psf.upfronthosting.co.za>


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

By the way, it is NOT POSSIBLE TO UNLOAD modules implemented in C, even if there is no more Python reference to the module.

----------

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

From report at bugs.python.org  Wed May  4 11:08:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 09:08:15 +0000
Subject: [issue11996] libpython.py: nicer py-bt output
In-Reply-To: <1304500095.82.0.965528459857.issue11996@psf.upfronthosting.co.za>
Message-ID: <1304500095.82.0.965528459857.issue11996@psf.upfronthosting.co.za>


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

py-bt is too much verbose, I'm unable to read it.

Example:
--------------------
$ gdb -args ./python -c 'import time, threading; threading.Thread(target=lambda:time.sleep(3)).start()'
...
[New Thread 0x7ffff69d9700 (LWP 17193)]
^C
Program received signal SIGINT, Interrupt.
sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
86	../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S: Aucun fichier ou dossier de ce type.
	in ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S
(gdb) py-bt
#6 Frame 0xc52620, for file /home/haypo/prog/HG/cpython/Lib/threading.py, line 237, in wait (self=<_Condition(release=<built-in method release of _thread.lock object at remote 0xc1f1e0>, acquire=<built-in method acquire of _thread.lock object at remote 0xc1f1e0>, _lock=<_thread.lock at remote 0xc1f1e0>, _waiters=[<_thread.lock at remote 0xafb590>], _verbose=False) at remote 0xc1cbe0>, timeout=None, waiter=<_thread.lock at remote 0xafb590>, saved_state=None)
                waiter.acquire()
#10 Frame 0xbbb580, for file /home/haypo/prog/HG/cpython/Lib/threading.py, line 851, in join (self=<Thread(_target=<function at remote 0xbb5d30>, _block=<_Condition(release=<built-in method release of _thread.lock object at remote 0xc1f1e0>, acquire=<built-in method acquire of _thread.lock object at remote 0xc1f1e0>, _lock=<_thread.lock at remote 0xc1f1e0>, _waiters=[<_thread.lock at remote 0xafb590>], _verbose=False) at remote 0xc1cbe0>, _args=(), _initialized=True, _name='Thread-1', _daemonic=False, _kwargs={}, _stderr=<_io.TextIOWrapper at remote 0xac15a0>, _ident=140737330910976, _started=<_Event(_flag=True, _cond=<_Condition(release=<built-in method release of _thread.lock object at remote 0xad7e00>, acquire=<built-in method acquire of _thread.lock object at remote 0xad7e00>, _lock=<_thread.lock at remote 0xad7e00>, _waiters=[], _verbose=False) at remote 0xc1ce40>, _verbose=False) at remote 0xaec980>, _stopped=False, _verbose=False) at remote 0xc2fb70>, timeout=None)
                    self._block.wait()
#14 Frame 0xc42eb0, for file /home/haypo/prog/HG/cpython/Lib/threading.py, line 965, in _exitfunc (self=<_MainThread(_target=None, _block=<_Condition(release=<built-in method release of _thread.lock object at remote 0xc66290>, acquire=<built-in method acquire of _thread.lock object at remote 0xc66290>, _lock=<_thread.lock at remote 0xc66290>, _waiters=[], _verbose=False) at remote 0xc66110>, _args=(), _initialized=True, _name='MainThread', _daemonic=False, _kwargs={}, _stderr=<_io.TextIOWrapper at remote 0xac15a0>, _ident=140737353987840, _started=<_Event(_flag=True, _cond=<_Condition(release=<built-in method release of _thread.lock object at remote 0xc62fe0>, acquire=<built-in method acquire of _thread.lock object at remote 0xc62fe0>, _lock=<_thread.lock at remote 0xc62fe0>, _waiters=[], _verbose=False) at remote 0xc65d20>, _verbose=False) at remote 0xc65840>, _stopped=True, _verbose=False) at remote 0xc64c90>, t=<Thread(_target=<function at remote 0xbb5d30>, _block=<_Condition(release=<built-in method release o...(truncated)
            t.join()
--------------------

Attached patch uses a syntax closer to classic Python tracebacks:
--------------------
$ gdb -args ./python -c 'import time, threading; (gdb) run
...
[New Thread 0x7ffff69d9700 (LWP 17193)]
^C
Program received signal SIGINT, Interrupt.
sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
86	../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S: Aucun fichier ou dossier de ce type.
	in ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S
(gdb) py-bt
Traceback (most recent call first):
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 237, in wait
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 851, in join
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 965, in _exitfunc
(gdb) info threads
  2 Thread 0x7ffff69d9700 (LWP 17193)  0x00007ffff72a0c73 in select () at ../sysdeps/unix/syscall-template.S:82
* 1 Thread 0x7ffff7fdb700 (LWP 17190)  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
(gdb) thread 2
[Switching to thread 2 (Thread 0x7ffff69d9700 (LWP 17193))]#0  0x00007ffff72a0c73 in select ()
    at ../sysdeps/unix/syscall-template.S:82
82	../sysdeps/unix/syscall-template.S: Aucun fichier ou dossier de ce type.
	in ../sysdeps/unix/syscall-template.S
(gdb) py-bt
Traceback (most recent call first):
  File "<string>", line 1, in <lambda>
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 690, in run
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 737, in _bootstrap_inner
  File "/home/haypo/prog/HG/cpython/Lib/threading.py", line 710, in _bootstrap
--------------------

----------
components: Demos and Tools
files: gdb.patch
keywords: patch
messages: 135102
nosy: dmalcolm, haypo
priority: normal
severity: normal
status: open
title: libpython.py: nicer py-bt output
versions: Python 3.3
Added file: http://bugs.python.org/file21878/gdb.patch

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

From report at bugs.python.org  Wed May  4 11:11:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 09:11:17 +0000
Subject: [issue11996] libpython.py: nicer py-bt output
In-Reply-To: <1304500095.82.0.965528459857.issue11996@psf.upfronthosting.co.za>
Message-ID: <1304500277.9.0.0254869095395.issue11996@psf.upfronthosting.co.za>


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

I would also like a less verbose output for where, especially be able to hidden the value of the globals argument of PyEval_EvalCodeEx.

Example of where output:
-------------------
(gdb) where
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
#1  0x00000000004d5ff5 in PyThread_acquire_lock_timed (lock=0xc3bc50, microseconds=-1, intr_flag=1)
    at Python/thread_pthread.h:333
#2  0x00000000004db97e in acquire_timed (lock=0xc3bc50, microseconds=-1) at ./Modules/_threadmodule.c:66
#3  0x00000000004dbbc5 in lock_PyThread_acquire_lock (self=0xafb590, args=(), kwds=0x0) at ./Modules/_threadmodule.c:133
#4  0x00000000005931d6 in PyCFunction_Call (func=<built-in method acquire of _thread.lock object at remote 0xafb590>, arg=(), 
    kw=0x0) at Objects/methodobject.c:84
#5  0x0000000000489c6d in call_function (pp_stack=0x7fffffffb738, oparg=0) at Python/ceval.c:3859
#6  0x0000000000484791 in PyEval_EvalFrameEx (f=
    Frame 0xc52620, for file /home/haypo/prog/HG/cpython/Lib/threading.py, line 237, in wait (self=<_Condition(release=<built-in method release of _thread.lock object at remote 0xc1f1e0>, acquire=<built-in method acquire of _thread.lock object at remote 0xc1f1e0>, _lock=<_thread.lock at remote 0xc1f1e0>, _waiters=[<_thread.lock at remote 0xafb590>], _verbose=False) at remote 0xc1cbe0>, timeout=None, waiter=<_thread.lock at remote 0xafb590>, saved_state=None), throwflag=0) at Python/ceval.c:2657
#7  0x0000000000487db4 in PyEval_EvalCodeEx (_co=<code at remote 0xc32cd0>, globals=
    {'current_thread': <function at remote 0xc64170>, '_BoundedSemaphore': <type at remote 0xc503d0>, '_Semaphore': <type at remote 0xc4fc50>, '_Timer': <type at remote 0xc62a90>, '_format_exc': <function at remote 0xb7ca70>, 'Semaphore': <function at remote 0xc553a0>, 'activeCount': <function at remote 0xc64a30>, '_profile_hook': None, '_sleep': <built-in method sleep of module object at remote 0xc25e70>, '_trace_hook': None, 'ThreadError': <type at remote 0x865c00>, '_enumerate': <function at remote 0xc64ad0>, '_start_new_thread': <built-in method start_new_thread of module object at remote 0xa97150>, '_CRLock': <type at remote 0x83df80>, 'BoundedSemaphore': <function at remote 0xc4e710>, 'currentThread': <function at remote 0xc64170>, '__all__': ['active_count', 'Condition', 'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore', 'BoundedSemaphore', 'Thread', 'Barrier', 'Timer', 'setprofile', 'settrace', 'local', 'stack_size'], '_Event': <type at remote 0xc43300>, '_PyRLock': <type at remote 0xc4...(truncated), locals=0x0, args=0xbbb728, argcount=1, kws=0xbbb730, kwcount=0, defs=0xc4ec28, defcount=1, kwdefs=0x0, 
    closure=0x0) at Python/ceval.c:3295
#8  0x000000000048a26b in fast_function (func=<function at remote 0xc4eb60>, pp_stack=0x7fffffffc418, n=1, na=1, nk=0)
    at Python/ceval.c:3957
#9  0x0000000000489e43 in call_function (pp_stack=0x7fffffffc418, oparg=0) at Python/ceval.c:3880
#10 0x0000000000484791 in PyEval_EvalFrameEx (f=
    Frame 0xbbb580, for file /home/haypo/prog/HG/cpython/Lib/threading.py, line 851, in join (self=<Thread(_target=<function at remote 0xbb5d30>, _block=<_Condition(release=<built-in method release of _thread.lock object at remote 0xc1f1e0>, acquire=<built-in method acquire of _thread.lock object at remote 0xc1f1e0>, _lock=<_thread.lock at remote 0xc1f1e0>, _waiters=[<_thread.lock at remote 0xafb590>], _verbose=False) at remote 0xc1cbe0>, _args=(), _initialized=True, _name='Thread-1', _daemonic=False, _kwargs={}, _stderr=<_io.TextIOWrapper at remote 0xac15a0>, _ident=140737330910976, _started=<_Event(_flag=True, _cond=<_Condition(release=<built-in method release of _thread.lock object at remote 0xad7e00>, acquire=<built-in method acquire of _thread.lock object at remote 0xad7e00>, _lock=<_thread.lock at remote 0xad7e00>, _waiters=[], _verbose=False) at remote 0xc1ce40>, _verbose=False) at remote 0xaec980>, _stopped=False, _verbose=False) at remote 0xc2fb70>, timeout=None), throwflag=0) at Python/ceval.c:2657
#11 0x0000000000487db4 in PyEval_EvalCodeEx (_co=<code at remote 0xc282d0>, globals=
    {'current_thread': <function at remote 0xc64170>, '_BoundedSemaphore': <type at remote 0xc503d0>, '_Semaphore': <type at remote 0xc4fc50>, '_Timer': <type at remote 0xc62a90>, '_format_exc': <function at remote 0xb7ca70>, 'Semaphore': <function at remote 0xc553a0>, 'activeCount': <function at remote 0xc64a30>, '_profile_hook': None, '_sleep': <built-in method sleep of module object at remote 0xc25e70>, '_trace_hook': None, 'ThreadError': <type at remote 0x865c00>, '_enumerate': <function at remote 0xc64ad0>, '_start_new_thread': <built-in method start_new_thread of module object at remote 0xa97150>, '_CRLock': <type at remote 0x83df80>, 'BoundedSemaphore': <function at remote 0xc4e710>, 'currentThread': <function at remote 0xc64170>, '__all__': ['active_count', 'Condition', 'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore', 'BoundedSemaphore', 'Thread', 'Barrier', 'Timer', 'setprofile', 'settrace', 'local', 'stack_size'], '_Event': <type at remote 0xc43300>, '_PyRLock': <type at remote 0xc4...(truncated), locals=0x0, args=0xc43048, argcount=1, kws=0xc43050, kwcount=0, defs=0xc457a8, defcount=1, kwdefs=0x0, 
    closure=0x0) at Python/ceval.c:3295
#12 0x000000000048a26b in fast_function (func=<function at remote 0xc61e00>, pp_stack=0x7fffffffd0f8, n=1, na=1, nk=0)
    at Python/ceval.c:3957
-------------------

Without python-gdb.py:
-------------------
(gdb) where
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
#1  0x00000000004d5ff5 in PyThread_acquire_lock_timed (lock=0xc3bc50, microseconds=-1, intr_flag=1)
    at Python/thread_pthread.h:333
#2  0x00000000004db97e in acquire_timed (lock=0xc3bc50, microseconds=-1) at ./Modules/_threadmodule.c:66
#3  0x00000000004dbbc5 in lock_PyThread_acquire_lock (self=0xafb590, args=0x8977a0, kwds=0x0) at ./Modules/_threadmodule.c:133
#4  0x00000000005931d6 in PyCFunction_Call (func=0xc670d0, arg=0x8977a0, kw=0x0) at Objects/methodobject.c:84
#5  0x0000000000489c6d in call_function (pp_stack=0x7fffffffb738, oparg=0) at Python/ceval.c:3859
#6  0x0000000000484791 in PyEval_EvalFrameEx (f=0xc52620, throwflag=0) at Python/ceval.c:2657
#7  0x0000000000487db4 in PyEval_EvalCodeEx (_co=0xc32cd0, globals=0xb86dd0, locals=0x0, args=0xbbb728, argcount=1, 
    kws=0xbbb730, kwcount=0, defs=0xc4ec28, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3295
#8  0x000000000048a26b in fast_function (func=0xc4eb60, pp_stack=0x7fffffffc418, n=1, na=1, nk=0) at Python/ceval.c:3957
#9  0x0000000000489e43 in call_function (pp_stack=0x7fffffffc418, oparg=0) at Python/ceval.c:3880
#10 0x0000000000484791 in PyEval_EvalFrameEx (f=0xbbb580, throwflag=0) at Python/ceval.c:2657
#11 0x0000000000487db4 in PyEval_EvalCodeEx (_co=0xc282d0, globals=0xb86dd0, locals=0x0, args=0xc43048, argcount=1, 
    kws=0xc43050, kwcount=0, defs=0xc457a8, defcount=1, kwdefs=0x0, closure=0x0) at Python/ceval.c:3295
#12 0x000000000048a26b in fast_function (func=0xc61e00, pp_stack=0x7fffffffd0f8, n=1, na=1, nk=0) at Python/ceval.c:3957
#13 0x0000000000489e43 in call_function (pp_stack=0x7fffffffd0f8, oparg=0) at Python/ceval.c:3880
#14 0x0000000000484791 in PyEval_EvalFrameEx (f=0xc42eb0, throwflag=0) at Python/ceval.c:2657
#15 0x0000000000487db4 in PyEval_EvalCodeEx (_co=0xc2f6b0, globals=0xb86dd0, locals=0x0, args=0xc2fe78, argcount=1, kws=0x0, 
    kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3295
#16 0x0000000000574aa5 in function_call (func=0xc63c70, arg=0xc2fe50, kw=0x0) at Objects/funcobject.c:629
#17 0x000000000053dd47 in PyObject_Call (func=0xc63c70, arg=0xc2fe50, kw=0x0) at Objects/abstract.c:2149
#18 0x000000000055a0ea in method_call (func=0xc63c70, arg=0xc2fe50, kw=0x0) at Objects/classobject.c:319
#19 0x000000000053dd47 in PyObject_Call (func=0xb0cde0, arg=0x8977a0, kw=0x0) at Objects/abstract.c:2149
#20 0x000000000053ded4 in call_function_tail (callable=0xb0cde0, args=0x8977a0) at Objects/abstract.c:2181
#21 0x000000000053e306 in PyObject_CallMethod (o=0xc52f40, name=0x5d57ba "_shutdown", format=0x5d4c3d "")
    at Objects/abstract.c:2258
#22 0x00000000004bfbc3 in wait_for_thread_shutdown () at Python/pythonrun.c:2208
#23 0x00000000004bad56 in Py_Finalize () at Python/pythonrun.c:386
#24 0x00000000004d92e9 in Py_Main (argc=3, argv=0x896010) at Modules/main.c:712
#25 0x0000000000419327 in main (argc=3, argv=0x7fffffffe1e8) at ./Modules/python.c:59
-------------------

----------

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

From report at bugs.python.org  Wed May  4 11:29:06 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 04 May 2011 09:29:06 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1304501346.78.0.307469642836.issue11990@psf.upfronthosting.co.za>


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

Do you have a test scipt for us to reproduce the issues?

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

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

From report at bugs.python.org  Wed May  4 11:40:17 2011
From: report at bugs.python.org (Daniel Evers)
Date: Wed, 04 May 2011 09:40:17 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304502017.16.0.803111750901.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

Thanks for the tip. I added the unit test and uploaded my final patch (which includes all changes).
Is it ok to remove the files I uploaded previously?

----------
Added file: http://bugs.python.org/file21879/backlog0_complete.patch

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

From report at bugs.python.org  Wed May  4 11:51:26 2011
From: report at bugs.python.org (Miquel Torres)
Date: Wed, 04 May 2011 09:51:26 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1304502686.69.0.0531015368418.issue4106@psf.upfronthosting.co.za>


Miquel Torres <tobami at gmail.com> added the comment:

I can confirm this but with Python 2.7.1 on Ubuntu 11.04 64bit

My code was working with a queue that was being fed a two-string tuple.
When i changed it to contain my custom Objects, it still worked correctly, but the main program doesn't end until it raises the exception in QueueFeederThread

----------
nosy: +tobami
versions: +Python 2.7

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

From report at bugs.python.org  Wed May  4 11:53:57 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 04 May 2011 09:53:57 +0000
Subject: [issue11997] One typo in Doc/c-api/init.rst
In-Reply-To: <1304502837.0.0.265474702081.issue11997@psf.upfronthosting.co.za>
Message-ID: <1304502837.0.0.265474702081.issue11997@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Yes, i really found a typo.
I'll send two patches, one with the typo fixed,
and one with the typo fixed and one for which
i've :setlocal tw=80:{gq}

----------
assignee: docs at python
components: Documentation
messages: 135107
nosy: docs at python, sdaoden
priority: normal
severity: normal
status: open
title: One typo in Doc/c-api/init.rst
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed May  4 11:59:44 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 04 May 2011 09:59:44 +0000
Subject: [issue11997] One typo in Doc/c-api/init.rst
In-Reply-To: <1304502837.0.0.265474702081.issue11997@psf.upfronthosting.co.za>
Message-ID: <20110504095935.GA40536@sherwood.local>


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

11997.1.diff only corrects the typo, 11997.2.diff does also
reformat.  (Note that all of init.rst is hard to read on a 80
column terminal.)

----------
keywords: +patch
Added file: http://bugs.python.org/file21880/11997.1.diff
Added file: http://bugs.python.org/file21881/11997.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11997>
_______________________________________
-------------- next part --------------
diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -883,7 +883,7 @@
 modules.
 
 Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
-is delicate, become these APIs assume a bijection between Python thread states
+is delicate, because these APIs assume a bijection between Python thread states
 and OS-level threads, an assumption broken by the presence of sub-interpreters.
 It is highly recommended that you don't switch sub-interpreters between a pair
 of matching :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` calls.
-------------- next part --------------
diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
--- a/Doc/c-api/init.rst
+++ b/Doc/c-api/init.rst
@@ -882,14 +882,14 @@
 by such objects may affect the wrong (sub-)interpreter's dictionary of loaded
 modules.
 
-Also note that combining this functionality with :c:func:`PyGILState_\*` APIs
-is delicate, become these APIs assume a bijection between Python thread states
-and OS-level threads, an assumption broken by the presence of sub-interpreters.
-It is highly recommended that you don't switch sub-interpreters between a pair
-of matching :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` calls.
-Furthermore, extensions (such as :mod:`ctypes`) using these APIs to allow calling
-of Python code from non-Python created threads will probably be broken when using
-sub-interpreters.
+Also note that combining this functionality with :c:func:`PyGILState_\*` APIs is
+delicate, because these APIs assume a bijection between Python thread states and
+OS-level threads, an assumption broken by the presence of sub-interpreters.  It
+is highly recommended that you don't switch sub-interpreters between a pair of
+matching :c:func:`PyGILState_Ensure` and :c:func:`PyGILState_Release` calls.
+Furthermore, extensions (such as :mod:`ctypes`) using these APIs to allow
+calling of Python code from non-Python created threads will probably be broken
+when using sub-interpreters.
 
 
 Asynchronous Notifications

From report at bugs.python.org  Wed May  4 12:30:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 10:30:40 +0000
Subject: [issue11998] test_signal cannot test blocked signals if _tkinter is
	loaded
In-Reply-To: <1304505040.09.0.715253576105.issue11998@psf.upfronthosting.co.za>
Message-ID: <1304505040.09.0.715253576105.issue11998@psf.upfronthosting.co.za>


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

I'm working on signals, especially on pthread_sigmask(), and I'm trying to understand test_signal failures.

test_signal fails if the _tkinter module is loaded, because _tkinter loads the Tcl library which create a thread waiting events in select(). For example, "python -m test test_pydoc test_signal" fails, because test_pydoc loads ALL Python modules. I opened an issue for test_pydoc: http://bugs.python.org/issue11995

_tkinter.c contains the following code:
#if 0
    /* This was not a good idea; through <Destroy> bindings,
       Tcl_Finalize() may invoke Python code but at that point the
       interpreter and thread state have already been destroyed! */
    Py_AtExit(Tcl_Finalize);
#endif

Tcl_Finalize() exits the thread, but this function is never called in Python. Anyway, it is not possible to unload a module implemented in C.

I would like to know if it would be possible to mask all signals in the Tcl thread, or if Tcl supports/uses signals.

It is possible to mask all signals in the Tcl thread using:
----------
allsignals = range(1, signal.NSIG)
oldmask = signal.pthread_sigmask(signal.SIG_BLOCK, allsignals)
import _tkinter
signal.pthread_sigmask(signal.SIG_SETMASK, oldmask)
----------

I'm not asking the question for test_signal: I have a patch fixing test_signal, even if the Tcl zombi thread is present (use pthread_kill() to send the signal directly to the main thread).

(I wrote "zombi" thread because I was not aware that Tcl uses a thread,
nor that test_pydoc loads all modules. The thread is valid, alive, and
it's just a joke. The threads is more hidden than zombi.)

(Message copied/pasted from python-dev)

----------
components: Tests, Tkinter
messages: 135109
nosy: haypo
priority: normal
severity: normal
status: open
title: test_signal cannot test blocked signals if _tkinter is loaded
versions: Python 3.3

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

From report at bugs.python.org  Wed May  4 12:35:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 10:35:38 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1304505338.02.0.265038022883.issue11995@psf.upfronthosting.co.za>


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

See also #11998 for test_signal and _tkinter issue (test_pydoc + test_signal).

----------

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

From report at bugs.python.org  Wed May  4 12:38:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 10:38:23 +0000
Subject: [issue11998] test_signal cannot test blocked signals if _tkinter is
	loaded
In-Reply-To: <1304505040.09.0.715253576105.issue11998@psf.upfronthosting.co.za>
Message-ID: <E1QHZTG-0002O4-AW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 88dca05ed468 by Victor Stinner in branch 'default':
Issue #11998, issue #8407: workaround _tkinter issue in test_signal
http://hg.python.org/cpython/rev/88dca05ed468

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

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

From report at bugs.python.org  Wed May  4 12:40:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 10:40:43 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304505643.13.0.544313610223.issue8407@psf.upfronthosting.co.za>


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

> c) Skip the test if the _tkinter thread is present (...)

I opened issue #11998 for the problem with test_signal and the _tkinter module. To get back green buildbots, I commited a workaround:

New changeset 88dca05ed468 by Victor Stinner in branch 'default':
Issue #11998, issue #8407: workaround _tkinter issue in test_signal
http://hg.python.org/cpython/rev/88dca05ed468

> a) Use pthread_kill() to send the signal directly
> to the right thread (...)

I'm still working on this solution to test blocked signals even if _tkinter is loaded.

----------

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

From report at bugs.python.org  Wed May  4 13:05:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 11:05:50 +0000
Subject: [issue11998] test_signal cannot test blocked signals if _tkinter is
	loaded
In-Reply-To: <1304505040.09.0.715253576105.issue11998@psf.upfronthosting.co.za>
Message-ID: <1304507150.45.0.378527526667.issue11998@psf.upfronthosting.co.za>


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

As suggested by Antoine, here is a patch to call Tcl_Finalize() in test_signal.

You can call create a Tcl/Tk window, destroy it, call _tkinter._finalize(), and then create a new Tcl/Tk window. But call _tkinter._finalize() crashes if there is still a running Tcl/Tk window.

We should add a safety test checking that there is no more running widget. If it is not possible to implement this, the function should only be compiled in debug mode. If it is possible, it would be nice to call _tkinter._finalize() when the last widget is destroyed and/or at Python exit.

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file21882/tkinter_finalize.patch

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

From report at bugs.python.org  Wed May  4 13:09:29 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 May 2011 11:09:29 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304507369.32.0.110872901941.issue11873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A quick eyeball of the test doesn't reveal anything obvious:

- if the subprocess is failing, it is doing so in such a way that it is still returning a 0 error code and isn't writing anything to stdout (as those assertions are before the check that the expected compiled file exists)
- the invocation of script_helper looks sensible
- if the directory creation fails, it won't get as far as running the subprocess

To instrument this, I would suggest starting by adding an assertion message on the failing assertion that includes "fn". My guess is that with the random directory name in there, the regex is triggering on the directory name and hence excluding the __init__.py file as well.

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

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

From report at bugs.python.org  Wed May  4 13:12:56 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 04 May 2011 11:12:56 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1304507576.36.0.068778595296.issue11834@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It's always a pleasure. ;)

----------

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

From report at bugs.python.org  Wed May  4 13:14:31 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 May 2011 11:14:31 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304507671.82.0.709411424475.issue11873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, I probably should have revised the first half of my comment after I had the thought about "simple regex" + "random directory name" being potentially problematic. I don't think that theory really counts as obvious, though...

----------

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

From report at bugs.python.org  Wed May  4 13:17:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 11:17:27 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>


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

test_mailbox fails sometimes on FreeBSD. Recent example on AMD FreeBSD 8.2 3.x:
---------------
[200/354] test_mailbox
test test_mailbox failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_mailbox.py", line 905, in test_reread
    assert refreshed()
AssertionError
---------------
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/180/steps/test/logs/stdio

----------
components: Library (Lib), Tests
messages: 135117
nosy: haypo
priority: normal
severity: normal
status: open
title: sporadic failure in test_mailbox on FreeBSD
versions: Python 3.3

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

From report at bugs.python.org  Wed May  4 13:20:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 11:20:46 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QHa8K-00068J-Qm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a5890ff5e3d5 by Victor Stinner in branch 'default':
Issue #8407: signal.pthread_sigmask() returns a set instead of a list
http://hg.python.org/cpython/rev/a5890ff5e3d5

----------

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

From report at bugs.python.org  Wed May  4 13:35:52 2011
From: report at bugs.python.org (Nicolas Bareil)
Date: Wed, 04 May 2011 11:35:52 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>


New submission from Nicolas Bareil <nico at chdir.org>:

When connecting to a SSL server, the certificate verification failed if
it has a subjectAltName extension without any dNSName entry inside: it
should fallback to the Common Name.

Example:

    >>> cert = conn.getpeercert()
    >>> cert
    {'notAfter': 'May 15 14:31:42 2011 GMT',
     'subject': ((('countryName', u'FR'),),
                 (('stateOrProvinceName', u'Ile-de-France'),),
                 (('localityName', u'Paris'),),
                 (('organizationName', 'xxx'),),
                 (('organizationalUnitName', 'xxx'),),
                 (('commonName', 'foobar.corp'),),
                 (('emailAddress', u'test at test.net'),)),
     'subjectAltName': (('email', text at test.net'),)}


This certificate is valid according to RFC 2818:

    If a subjectAltName extension of type dNSName is present, that MUST
    be used as the identity. Otherwise, the (most specific) Common Name
    field in the Subject field of the certificate MUST be used. Although
    the use of the Common Name is existing practice, it is deprecated and
    Certification Authorities are encouraged to use the dNSName instead.

Even if the use of CommonName is deprecated, we should not break
existing systems.

Current revision of Lib/ssl.py :

    108 def match_hostname(cert, hostname):
    ...
    119     san = cert.get('subjectAltName', ())
    120     for key, value in san:
    121         if key == 'DNS':
    122             if _dnsname_to_pat(value).match(hostname):
    123                 return
    124             dnsnames.append(value)
    125     if not san:
    126         # The subject is only checked when subjectAltName is empty
    127         for sub in cert.get('subject', ()):
    128             for key, value in sub:
    129                 # XXX according to RFC 2818, the most specific Common Name
    130                 # must be used.
    131                 if key == 'commonName':
    132                     if _dnsname_to_pat(value).match(hostname):
    133                         return
    134                     dnsnames.append(value)
    ...

Proposed patch is:


diff -r 513f6dfd3173 Lib/ssl.py
--- a/Lib/ssl.py        Sun May 01 20:24:59 2011 -0500
+++ b/Lib/ssl.py        Mon May 02 11:16:46 2011 +0200
@@ -122,8 +122,9 @@
             if _dnsname_to_pat(value).match(hostname):
                 return
             dnsnames.append(value)
- if not san:
- # The subject is only checked when subjectAltName is empty
+ if not san and not dnsnames:
+ # The subject is only checked when there is no dNSName entry
+ # in subjectAltName
  for sub in cert.get('subject', ()):
      for key, value in sub:
          # XXX according to RFC 2818, the most specific Common Name

----------
components: Library (Lib)
messages: 135119
nosy: nbareil
priority: normal
severity: normal
status: open
title: SSL certificate verification failed if no dNSName entry in subjectAltName
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May  4 13:41:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 11:41:48 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <E1QHaSZ-0007lL-S2@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9d5a50e5d8a2 by Ezio Melotti in branch '2.7':
#11982: fix json.loads('""') to return u'' rather than ''.
http://hg.python.org/cpython/rev/9d5a50e5d8a2

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

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

From report at bugs.python.org  Wed May  4 13:46:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 May 2011 11:46:32 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <1304509592.44.0.81622177225.issue11982@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

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

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

From report at bugs.python.org  Wed May  4 13:49:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 11:49:28 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304509768.54.0.93645528495.issue8407@psf.upfronthosting.co.za>


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

pending_signals.patch: add pthread_kill(), sigpending() and sigwait() functions with doc and tests.

I added many "See also" in the doc, e.g. os.kill() gives a link to signal.pthread_kill().

Note: the patch renames also BasicSignalTests to PosixTests, it's not related to the other changes.

----------
Added file: http://bugs.python.org/file21883/pending_signals.patch

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

From report at bugs.python.org  Wed May  4 13:53:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 11:53:37 +0000
Subject: [issue11998] test_signal cannot test blocked signals if _tkinter is
	loaded; Tcl_Finalize()
In-Reply-To: <1304505040.09.0.715253576105.issue11998@psf.upfronthosting.co.za>
Message-ID: <1304510017.92.0.895403625204.issue11998@psf.upfronthosting.co.za>


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


----------
title: test_signal cannot test blocked signals if _tkinter is loaded -> test_signal cannot test blocked signals if _tkinter is loaded; Tcl_Finalize()

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

From report at bugs.python.org  Wed May  4 14:00:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 12:00:37 +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: <1304510437.54.0.278213493777.issue11277@psf.upfronthosting.co.za>


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

Reopen, test_zlib fails with Python 2.7 on Windows:

======================================================================
ERROR: test_big_buffer (test.test_zlib.ChecksumBigBufferTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\test\test_zlib.py", line 91, in test_big_buffer
    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
WindowsError: [Error 87] The parameter is incorrect

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

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

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

From report at bugs.python.org  Wed May  4 14:02:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 12:02:22 +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: <E1QHama-0001MN-Rb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1ef2a7319849 by Victor Stinner in branch '2.7':
Issue #11277: fix issue number in a test_zlib comment
http://hg.python.org/cpython/rev/1ef2a7319849

----------

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

From report at bugs.python.org  Wed May  4 14:08:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 12:08:11 +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: <1304510891.95.0.238394453166.issue11277@psf.upfronthosting.co.za>


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

"x86 debian parallel 2.7", "x86 Ubuntu Shared 2.7" and "x86 Tiger 2.7" fail with mmap.error('[Errno 12] Cannot allocate memory').

http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%202.7/builds/866/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%202.7/builds/776/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20debian%20parallel%202.7/builds/739/steps/test/logs/stdio
======================================================================
ERROR: test_big_buffer (test.test_zlib.ChecksumBigBufferTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/test/test_zlib.py", line 91, in test_big_buffer
    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
error: [Errno 12] Cannot allocate memory

----------

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

From report at bugs.python.org  Wed May  4 14:09:27 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 04 May 2011 12:09:27 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <20110504120918.GA74777@sherwood.local>


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

I think this relates #6896.
Maybe a two second resolution should be tried?

----------
keywords: +patch
nosy: +sdaoden
Added file: http://bugs.python.org/file21884/11999.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -514,13 +514,11 @@
             else:
                 return
 
-        # We record the current time - 1sec so that, if _refresh() is called
-        # again in the same second, we will always re-read the mailbox
-        # just in case it's been modified.  (os.path.mtime() only has
-        # 1sec resolution.)  This results in a few unnecessary re-reads
-        # when _refresh() is called multiple times in the same second,
-        # but once the clock ticks over, we will only re-read as needed.
-        now = time.time() - 1
+        # Try to be fancy by using a date in the past for our _last_read mtime
+        # checks (see issues #6896, #11999)
+        # Using a two second resolution should be enough to overcome all
+        # fuzziness which may be introduced along the different filesystems.
+        now = time.time() - 2
 
         self._toc = {}
         def update_dir (subdir):

From report at bugs.python.org  Wed May  4 14:21:30 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 04 May 2011 12:21:30 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1304511690.68.0.0557427407433.issue10946@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/issue10946>
_______________________________________

From report at bugs.python.org  Wed May  4 14:28:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 12:28:47 +0000
Subject: [issue11982] json.loads() returns str instead of unicode for empty
	strings
In-Reply-To: <1304386530.0.0.240927955251.issue11982@psf.upfronthosting.co.za>
Message-ID: <E1QHbC8-00048t-VF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d3bd384df8ca by Ezio Melotti in branch '2.7':
#11982: remove now unused function.
http://hg.python.org/cpython/rev/d3bd384df8ca

----------

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

From report at bugs.python.org  Wed May  4 14:30:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 May 2011 12:30:59 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304512259.39.0.696550564911.issue11999@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/issue11999>
_______________________________________

From report at bugs.python.org  Wed May  4 14:42:31 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 04 May 2011 12:42:31 +0000
Subject: [issue11834] wrong module installation dir on Windows
In-Reply-To: <1302605256.31.0.234550103785.issue11834@psf.upfronthosting.co.za>
Message-ID: <1304512951.68.0.729402979848.issue11834@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


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

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

From report at bugs.python.org  Wed May  4 15:04:15 2011
From: report at bugs.python.org (Peter Le Bek)
Date: Wed, 04 May 2011 13:04:15 +0000
Subject: [issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for
	C++"
In-Reply-To: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za>
Message-ID: <1304514255.31.0.95114309248.issue5755@psf.upfronthosting.co.za>


Peter Le Bek <peter at hyperplex.net> added the comment:

distutils reuses whatever flags Python was built with, covered here: http://bugs.python.org/issue1222585 (and here http://bugs.python.org/issue9031).

----------
nosy: +vokoda

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

From report at bugs.python.org  Wed May  4 15:48:13 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 04 May 2011 13:48:13 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1304510891.95.0.238394453166.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110504134803.GA18501@sherwood.local>


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

> error: [Errno 12] Cannot allocate memory

@haypo: Well i told you i have no idea.  These bots are 32 bit?

I'll attach 11277-27.3.diff which does @skipUnless(not 32 bit).
Note i'll test against >_4G - does this work (on 32 bit and in
Python)?  A pity that Python does not offer a 'condition is
always true due to datatype storage restriction' check?!

And i don't think it makes sense to test a _1GB mmap on 32 bit at
all (but at least address space shouldn't exhaust for that).
So, sorry, also for the two bugs in that two-liner, but very
especially the 'm' case.

----------
Added file: http://bugs.python.org/file21885/11277-27.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_zlib.py b/Lib/test/test_zlib.py
--- a/Lib/test/test_zlib.py
+++ b/Lib/test/test_zlib.py
@@ -2,7 +2,7 @@
 from test.test_support import TESTFN, run_unittest, import_module, unlink, requires
 import binascii
 import random
-from test.test_support import precisionbigmemtest, _1G
+from test.test_support import precisionbigmemtest, _1G, _2G, _4G
 import sys
 
 try:
@@ -75,17 +75,16 @@
 # Issue #11277 - check that inputs of 2 GB are handled correctly.
 # Be aware of issues #1202, #8650, #8651 and #10276
 class ChecksumBigBufferTestCase(unittest.TestCase):
-    int_max = 0x7FFFFFFF
-
+    @unittest.skipUnless(sys.maxsize > _4G, "Can't run on a 32-bit system.")
     @unittest.skipUnless(mmap, "mmap() is not available.")
     def test_big_buffer(self):
         if sys.platform[:3] == 'win' or sys.platform == 'darwin':
             requires('largefile',
                      'test requires %s bytes and a long time to run' %
-                     str(self.int_max))
+                     str(_2G -1))
         try:
             with open(TESTFN, "wb+") as f:
-                f.seek(self.int_max-4)
+                f.seek(_2G -1-4)
                 f.write("asdf")
                 f.flush()
                 m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)

From report at bugs.python.org  Wed May  4 15:49:55 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 04 May 2011 13:49:55 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1304516995.51.0.992683831137.issue3526@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Another reason why you should not force dlmalloc for all applications linked with libpython is because dlmalloc is (by default) not thread safe, while the system malloc is (generally) thread-safe. It is possible to define a constant in dlmalloc to make it thread-safe (using locks) but it will be slower and it is not needed in Python since the GIL must be held when using PyMem_ functions.

If a thread-safe implementation was needed, it would be better to switch to ptmalloc2.

Also that addresses the issue of "two threads inside different malloc implementations at the same time": it is currently not allowed with PyMem_Malloc.

> Most of the allocations come from the heap - through sbrk

Most python objects will be allocated in pymalloc arenas (if they are smaller than 256 bytes) which (if compiled with --with-pymalloc-mmap) will be directly allocated by calling mmap, or (without --with-pymalloc-mmap) will be allocated in dlmalloc by calling mmap (because arenas are 256KB).
So most of the python objects will end up in mmap segments separate from the heap.

The only allocations that will end up in the heap are for the medium python objects (>256 bytes and <256KB) or for allocations directly by calling  PyMem_Malloc (and for a size <256KB). Also dlmalloc will not call sbrk for each of those allocations: dlmalloc allocates some large memory pools and manage the smaller allocations within those pools in a very efficient way. So the heap fragmentation should be indeed reduced by using dlmalloc.

Most modern malloc implementations are also using pools/arenas anyway, so the heap will mostly contain a mix of native malloc arenas and dlmalloc pools. So the fragmentation should not be too much of a concern if you mix 2 malloc implementations.
Here is OpenSolaris malloc implementation for example:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libmalloc/common/malloc.c#514

Concerning trimming: the reason why I am proposing to use dlmalloc on AIX and Solaris is that the native malloc/free do not correctly trim the heap in the first place on those platforms! If malloc/free correctly worked on those platforms and the heap was trimmed when possible, I would not have taken the trouble of proposing this patch and using dlmalloc, I would happily use the native malloc/free.

So mixing 2 malloc implementations should not be a problem as long as you keep track of the right 'free' implementation to use for each pointer (which should already be the case when you call PyMem_Malloc/PyMem_Free instead of malloc/free).

If you are really concerned about mixing 2 malloc implementations in the heap, you can define "HAVE_MORECORE 0" in dlmalloc and that way dlmalloc will always use mmap and not use the heap at all.

My application uses the provided patch so that dlmalloc is used for Python objects and the native malloc for all the rest (much less consuming than the Python part) on AIX and SunOS. It has been in production for years and we never experienced any crash related to memory problems.

----------

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

From report at bugs.python.org  Wed May  4 16:18:51 2011
From: report at bugs.python.org (Glenn Ammons)
Date: Wed, 04 May 2011 14:18:51 +0000
Subject: [issue12001] Extend json.dumps to handle N-triples strings
In-Reply-To: <1304518731.8.0.661491806451.issue12001@psf.upfronthosting.co.za>
Message-ID: <1304518731.8.0.661491806451.issue12001@psf.upfronthosting.co.za>


New submission from Glenn Ammons <glenn.ammons at gmail.com>:

The string format used in N-triples is very similar to that used in JSON (see http://www.w3.org/TR/rdf-testcases/#ntrip_strings).  It would be handy if json.dumps could (optionally) follow the N-triples format.  The differences are

1) In \u escapes, the hexadecimal digits must be capitalized.
2) N-triples uses \u escapes instead of \b and \f

----------
components: Extension Modules
messages: 135131
nosy: Glenn.Ammons
priority: normal
severity: normal
status: open
title: Extend json.dumps to handle N-triples strings
type: feature request
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed May  4 16:44:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 04 May 2011 14:44:27 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304438739.13.0.39868574652.issue11949@psf.upfronthosting.co.za>
Message-ID: <BANLkTikAS3ajh6XnKzfgh3P5c8nXKuYdHQ@mail.gmail.com>


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

On Tue, May 3, 2011 at 12:05 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> I was thinking of something like the rAssertAlmostEqual method in test_cmath.

This one is good.  I wonder if it would be appropriate to move
rAssertAlmostEqual() up to unitetest.case possibly replacing
assertAlmostEqual()? If replacing assertAlmostEqual() is not an
option, I would call it assertFloatAlmostEqual().

----------

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

From report at bugs.python.org  Wed May  4 16:45:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 May 2011 14:45:22 +0000
Subject: [issue12001] Extend json.dumps to handle N-triples strings
In-Reply-To: <1304518731.8.0.661491806451.issue12001@psf.upfronthosting.co.za>
Message-ID: <1304520322.03.0.37069859118.issue12001@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib)
nosy: +ezio.melotti
versions: +Python 3.3 -Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed May  4 17:32:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 04 May 2011 15:32:56 +0000
Subject: [issue11985] Document that platform.python_implementation supports
	PyPy
In-Reply-To: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>
Message-ID: <1304523176.58.0.9820821694.issue11985@psf.upfronthosting.co.za>


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

Could you update the docstring as well?

----------

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

From report at bugs.python.org  Wed May  4 17:40:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 15:40:16 +0000
Subject: [issue11985] Document that platform.python_implementation supports
	PyPy
In-Reply-To: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>
Message-ID: <E1QHeBQ-000795-GK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset affec521b330 by Ezio Melotti in branch '2.7':
#11985: update docstring of platform.python_implementation.
http://hg.python.org/cpython/rev/affec521b330

New changeset 7bf9d7ae6c94 by Ezio Melotti in branch '3.1':
#11985: update docstring of platform.python_implementation.
http://hg.python.org/cpython/rev/7bf9d7ae6c94

New changeset cc7342b4e59d by Ezio Melotti in branch '3.2':
#11985: merge with 3.1.
http://hg.python.org/cpython/rev/cc7342b4e59d

New changeset 6b95bf39842f by Ezio Melotti in branch 'default':
#11985: merge with 3.2.
http://hg.python.org/cpython/rev/6b95bf39842f

----------

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

From report at bugs.python.org  Wed May  4 17:42:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 04 May 2011 15:42:24 +0000
Subject: [issue11985] Document that platform.python_implementation supports
	PyPy
In-Reply-To: <1304442270.73.0.886848659063.issue11985@psf.upfronthosting.co.za>
Message-ID: <1304523744.46.0.451390676344.issue11985@psf.upfronthosting.co.za>


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

Thanks!

----------

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

From report at bugs.python.org  Wed May  4 18:05:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 04 May 2011 16:05:04 +0000
Subject: [issue11993] Use sub-second resolution to determine if a file is newer
In-Reply-To: <1304475832.41.0.871788475686.issue11993@psf.upfronthosting.co.za>
Message-ID: <1304525104.68.0.210223931615.issue11993@psf.upfronthosting.co.za>


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

To quote the initial message:

> If it were desired to determine which file was newer using sub-second
> values, perhaps that would make a reasonable change in distutils2,
> but files created with a few microseconds would have to be considered
> equivalent due to the reduced precision available in python floats
> (53 bits on my platform, if I understand correctly) as compared to
> the 64 bit precision used by some operating systems and file systems.

----------
title: Is it desired to distinguish new files from old with sub-second resolution? -> Use sub-second resolution to determine if a file is newer
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Wed May  4 18:06:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 04 May 2011 16:06:06 +0000
Subject: [issue11991] test_distutils fails because of bad filename match
In-Reply-To: <1304458084.66.0.88962395444.issue11991@psf.upfronthosting.co.za>
Message-ID: <1304525166.2.0.330758617475.issue11991@psf.upfronthosting.co.za>


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

Closing as duplicate.  Please join the discussion at #11340 if you have feedback or a patch :)

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_distutils fails because of borked compress program

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

From report at bugs.python.org  Wed May  4 18:08:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 04 May 2011 16:08:32 +0000
Subject: [issue11970] distutils command 'upload' crashes when --show-response
	is selected
In-Reply-To: <1304257341.36.0.351902747492.issue11970@psf.upfronthosting.co.za>
Message-ID: <1304525312.67.0.181536356053.issue11970@psf.upfronthosting.co.za>


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

Are you sure?  This looks like #10367 (unsolved yet), not #9199 (fixed).

----------

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

From report at bugs.python.org  Wed May  4 18:12:03 2011
From: report at bugs.python.org (Chris Rose)
Date: Wed, 04 May 2011 16:12:03 +0000
Subject: [issue11970] distutils command 'upload' crashes when --show-response
	is selected
In-Reply-To: <1304257341.36.0.351902747492.issue11970@psf.upfronthosting.co.za>
Message-ID: <1304525523.95.0.638077938777.issue11970@psf.upfronthosting.co.za>


Chris Rose <offby1 at offby1.net> added the comment:

No, not 100% sure, but my read of the 2.7 branch code certainly seemed to suggest that it was fixed.

in distutil/commands/upload.py:

Line 193 gets the response unconditionally as 'r' from the http object

Line 201 uses 'r' to show the response.

I might be missing a form that the 'r' object can take that isn't going to have a read() method, but I doubt it.

----------

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

From report at bugs.python.org  Wed May  4 18:13:32 2011
From: report at bugs.python.org (Chris Rose)
Date: Wed, 04 May 2011 16:13:32 +0000
Subject: [issue11970] distutils command 'upload' crashes when --show-response
	is selected
In-Reply-To: <1304257341.36.0.351902747492.issue11970@psf.upfronthosting.co.za>
Message-ID: <1304525612.72.0.810840050857.issue11970@psf.upfronthosting.co.za>


Chris Rose <offby1 at offby1.net> added the comment:

... oh, except I'm an idiot, and I think I'm reading tip code there. 

Yep, I'm an idiot.

Okay, but this is still a dupe of #10367

----------
resolution: invalid -> duplicate

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

From report at bugs.python.org  Wed May  4 18:14:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 04 May 2011 16:14:41 +0000
Subject: [issue11970] distutils command 'upload' crashes when --show-response
	is selected
In-Reply-To: <1304257341.36.0.351902747492.issue11970@psf.upfronthosting.co.za>
Message-ID: <1304525681.23.0.141215145083.issue11970@psf.upfronthosting.co.za>


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


----------
stage:  -> committed/rejected
superseder:  -> "python setup.py sdist upload --show-response" can fail with "UnboundLocalError: local variable 'result' referenced before assignment"

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

From report at bugs.python.org  Wed May  4 18:18:36 2011
From: report at bugs.python.org (James Hutchison)
Date: Wed, 04 May 2011 16:18:36 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1304525916.59.0.79592012085.issue11990@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

Yes and no, I can give you a single process single child example that just shows that python 3.2 uses binary output while python 3.1 used system default when piping, but trying to reproduce the multiprocessing output inconsistencies would be... difficult. Unfortunately the software I used to spot the \n, \r\n inconsistency with is proprietary. After creating a sample case in only python I couldn't reproduce the inconsistent \r\n issue in python 3.2 so I cannot say for certain that it wasn't caused by my C# program. I wouldn't worry about the inconsistent endlines for now.

Note that I don't see in the "what's new" documentation it mentioning that 3.2 changed the behavior of piped output. Kind of a big deal.

Sample code to compare 3.1 and 3.2 piped output:

import sys;
import os;
import subprocess;
from time import sleep;

python31loc = r"C:\python31\python.exe";
python32loc = r"C:\python32\python.exe";

myname = "IOPipetest.py";

def main(args):
    if(len(args) == 1):
        # main code
        print("Testing python 3.1 endlines.", end='\r\n');
        output = subprocess.check_output("%s %s -output" % (python31loc, myname));
        print(output);
        print("Testing python 3.2 endlines.", end='\r\n');
        output = subprocess.check_output("%s %s -output" % (python32loc, myname));
        print(output);
        sleep(7);
    else:
        for i in range(4):
            print("TESTING DEFAULT"); # endline is supposed to be automatic
            print("TESTING SLASH-EN\n", end='');
            print("TESTING WINDOW-RETURN\r\n", end='');
        

if __name__ == "__main__":
    main(sys.argv);

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

sample output:

Testing python 3.1 endlines.

b'TESTING DEFAULT\r\nTESTING SLASH-EN\r\nTESTING WINDOW-RETURN\r\r\nTESTING DEFAULT\r\nTESTING SLASH-EN\r\nTESTING WINDOW-RETURN\r\r\nTESTING DEFAULT\r\nTESTING SLASH-EN\r\nTESTING WINDOW-RETURN\r\r\nTESTING DEFAULT\r\nTESTING SLASH-EN\r\nTESTING WINDOW-RETURN\r\r\n'
Testing python 3.2 endlines.

b'TESTING DEFAULT\nTESTING SLASH-EN\nTESTING WINDOW-RETURN\r\nTESTING DEFAULT\nTESTING SLASH-EN\nTESTING WINDOW-RETURN\r\nTESTING DEFAULT\nTESTING SLASH-EN\nTESTING WINDOW-RETURN\r\nTESTING DEFAULT\nTESTING SLASH-EN\nTESTING WINDOW-RETURN\r\n'

----------

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

From report at bugs.python.org  Wed May  4 19:06:14 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 04 May 2011 17:06:14 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304528774.73.0.330161920703.issue11994@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Wed May  4 19:46:11 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 04 May 2011 17:46:11 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304531171.04.0.364600024233.issue11994@psf.upfronthosting.co.za>


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

STINNER Victor <report at bugs.python.org> wrote:
> You should try to disable compiler optimization: pass -O0 to gcc. E.g. use ./configure --with-pydebug CFLAGS="-O0".

I did, see "only occurs when python is compiled with optimizations". :)

----------

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

From report at bugs.python.org  Wed May  4 19:53:06 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 04 May 2011 17:53:06 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1304531586.82.0.818224989719.issue11995@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/issue11995>
_______________________________________

From report at bugs.python.org  Wed May  4 19:53:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 May 2011 17:53:48 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <BANLkTikzeM_Y5xodqeDUbOBuJ3qQU4hOnA@mail.gmail.com>
Message-ID: <1304531621.3568.11.camel@localhost.localdomain>


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

> - what's current_thread_id ? If it's thread_get_ident (pthread_self),
> since TID is not guaranteed to be inherited across fork, this won't
> work

Ouch, then the approach I'm proposing is probably doomed.

> And it's true with every lock in the library code: they're only held
> in short critical sections (typically acquired when entering a
> function and released when leaving), and since it's not the threads
> inside those libraries that fork, all those locks can simply be
> reinitialized on fork, without having the reacquire them.

Well, this means indeed that *some* locks can be handled, but not all of
them and not automatically, right?
Also, how would you propose they be dealt with in practice? How do they
get registered, and how does the reinitialization happen?

(do note that library code can call arbitrary third-party code, by the
way: for example through encodings in the text I/O layer)

----------

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

From report at bugs.python.org  Wed May  4 20:05:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 18:05:07 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <E1QHgRc-0003zF-JN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2a19d09b08f8 by Antoine Pitrou in branch '3.2':
Issue #1856: Avoid crashes and lockups when daemon threads run while the
http://hg.python.org/cpython/rev/2a19d09b08f8

New changeset c892b0321d23 by Antoine Pitrou in branch 'default':
Issue #1856: Avoid crashes and lockups when daemon threads run while the
http://hg.python.org/cpython/rev/c892b0321d23

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

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

From report at bugs.python.org  Wed May  4 20:05:40 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 04 May 2011 18:05:40 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1304532340.33.0.300943493507.issue11072@psf.upfronthosting.co.za>


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

Eric, any further comments about the patch?
Can we go on and commit it?

----------

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

From report at bugs.python.org  Wed May  4 20:06:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 May 2011 18:06:58 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1304532418.78.0.0553737491064.issue1856@psf.upfronthosting.co.za>


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

Should be fixed in 3.2 and 3.3 now. I don't really want to bother with 2.7 and 3.1 (the GIL implementation is different), but someone can backport the patch if they want to :)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed May  4 20:39:42 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 04 May 2011 18:39:42 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1304534382.29.0.959329580959.issue11995@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

It might be possible to use a part of patch for issue #1674555.
A newer version of that patch can be found in:
http://overlays.gentoo.org/svn/proj/python/overlays/python/dev-lang/python/files/3.3-20110417/23_all_tests_environment.patch

----------

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

From report at bugs.python.org  Wed May  4 20:46:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 04 May 2011 18:46:43 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1304516995.51.0.992683831137.issue3526@psf.upfronthosting.co.za>
Message-ID: <BANLkTin5g6gL5BVm_PigiU59Hwjc=uj9RQ@mail.gmail.com>


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

> Also that addresses the issue of "two threads inside different malloc implementations at the same time": it is currently not allowed with PyMem_Malloc.
>

That's not true.
You can perfectly have one thread inside PyMem_Malloc while another
one is inside libc's malloc.
For example, posix_listdir does:

     Py_BEGIN_ALLOW_THREADS
     dirp = opendir(name);
     Py_END_ALLOW_THREADS

Where opendir calls malloc internally. Since the GIL is released, you
can have another thread inside PyMem_Malloc at the same time. This is
perfectly safe, as long as the libc's malloc version is thread-safe.

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.
This thread-safety issue is not theoretical: I wrote up a small
program with two threads, one allocating/freeing memory in loop with
glibc's malloc and the other one with dlmalloc: it crashes immediately
on a Linux box.

> Most python objects will be allocated in pymalloc arenas (if they are smaller than 256 bytes) which (if compiled with --with-pymalloc-mmap) will be directly allocated by calling mmap, or (without --with-pymalloc-mmap) will be allocated in dlmalloc by calling mmap (because arenas are 256KB).
> So most of the python objects will end up in mmap segments separate from the heap.
>
> The only allocations that will end up in the heap are for the medium python objects (>256 bytes and <256KB) or for allocations directly by calling  PyMem_Malloc (and for a size <256KB).

Note that there are actually many objects falling into this category:
for example, on 64-bit, a dictionary exceeds 256B, and is thus
allocated directly from the heap (well, it changed really recently
actually), the same holds for medium-sized lists and strings. So,
depending on your workload, the heap can extend and shrink quite a
bit.

> If you are really concerned about mixing 2 malloc implementations in the heap, you can define "HAVE_MORECORE 0" in dlmalloc and that way dlmalloc will always use mmap and not use the heap at all.
>

It will also be slower, and consume more memory.

----------

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

From report at bugs.python.org  Wed May  4 20:58:57 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 04 May 2011 18:58:57 +0000
Subject: [issue11954] 3.3 - 'make test' fails
In-Reply-To: <1304078478.26.0.309792364849.issue11954@psf.upfronthosting.co.za>
Message-ID: <1304535537.92.0.502486712045.issue11954@psf.upfronthosting.co.za>


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

I just ran into this with test_httpserver/Python2.7, which fails if run
as root. If I understand correctly this is the main problem here. Jason,
do you agree to change the issue title to reflect this?

----------
nosy: +skrah
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  4 21:08:32 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 04 May 2011 19:08:32 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1304536112.13.0.450895521157.issue11049@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/issue11049>
_______________________________________

From report at bugs.python.org  Wed May  4 21:09:53 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 04 May 2011 19:09:53 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1304536193.6.0.293083786111.issue11015@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/issue11015>
_______________________________________

From report at bugs.python.org  Wed May  4 21:27:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 19:27:51 +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: <E1QHhjh-0003Cz-UH@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7f3cab59ef3e by Victor Stinner in branch '2.7':
Issue #11277: test_zlib tests a buffer of 1 GB on 32 bits
http://hg.python.org/cpython/rev/7f3cab59ef3e

----------

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

From report at bugs.python.org  Wed May  4 21:41:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 19:41:22 +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: <E1QHhwn-0004UL-FH@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e6a4deb84e47 by Victor Stinner in branch '2.7':
Issue #11277: oops, fix checksum values of test_zlib on 32 bits
http://hg.python.org/cpython/rev/e6a4deb84e47

----------

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

From report at bugs.python.org  Wed May  4 21:46:22 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 04 May 2011 19:46:22 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <E1QHhwn-0004UL-FH@dinsdale.python.org>
Message-ID: <20110504194609.GA60845@sherwood.local>


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

@haypo: Oh. Not:

   if sys.maxsize > _4G:
        # (64 bits system) crc32() and adler32() stores the buffer size into an
        # int, the maximum filesize is INT_MAX (0x7FFFFFFF)
        filesize = 0x7FFFFFFF
        crc_res = 0x709418e7
        adler_res = -2072837729
    else:
        # (32 bits system) On a 32 bits OS, a process cannot usually address
        # more than 2 GB, so test only 1 GB
        filesize = _1G
        crc_res = 0x2b09ee11
        adler_res = -1002962529

                    self.assertEqual(zlib.crc32(m), self.crc_res)
                    self.assertEqual(zlib.adler32(m), self.adler_res)

I'm not that fast.

----------

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

From report at bugs.python.org  Wed May  4 21:50:42 2011
From: report at bugs.python.org (Oren Held)
Date: Wed, 04 May 2011 19:50:42 +0000
Subject: [issue1516897] Use dynload_shlib on newer HP-UX versions
Message-ID: <1304538642.99.0.672028909899.issue1516897@psf.upfronthosting.co.za>


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

ajaksu2: the ticket you referred to fixed it for Darwin only, afaik. HP-UX, regardless of versions, still use the old dynload_hpux.c.

----------
nosy: +Oren_Held

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

From report at bugs.python.org  Wed May  4 21:51:09 2011
From: report at bugs.python.org (Oren Held)
Date: Wed, 04 May 2011 19:51:09 +0000
Subject: [issue1487481] Could BIND_FIRST be removed on HP-UX?
Message-ID: <1304538669.52.0.462132234207.issue1487481@psf.upfronthosting.co.za>


Changes by Oren Held <oren at held.org.il>:


----------
nosy: +Oren_Held

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

From report at bugs.python.org  Wed May  4 21:56:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 May 2011 19:56:48 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1304539008.77.0.643124646459.issue665194@psf.upfronthosting.co.za>


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

Here is a patch that adds datetime support to email.utils.formatdate.  Ultimately the email package will give programs access to datetime+timezone representations of the dates in various headers, so this provides the output end of the round trip.

Alexander, if you could review this that would be great.  There may be bugs in the logic of formatdate, but my hope is that I haven't added any new ones.

----------
nosy: +r.david.murray
stage: needs patch -> patch review
versions: +Python 3.3 -Python 3.2
Added file: http://bugs.python.org/file21886/formatdate_datetime_support.patch

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

From report at bugs.python.org  Wed May  4 22:06:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2011 20:06:44 +0000
Subject: [issue11335] Memory leak after key function failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <E1QHiLJ-00077I-Hi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 52fb7dc721ed by Daniel Stutzbach in branch '3.2':
#11335: Fix memory leak after key function failure in sort
http://hg.python.org/cpython/rev/52fb7dc721ed

New changeset 18e43c6acfff by Daniel Stutzbach in branch 'default':
#11335: Merge from 3.2: Fix memory leak after key function failure in sort
http://hg.python.org/cpython/rev/18e43c6acfff

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

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

From report at bugs.python.org  Wed May  4 22:08:26 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 04 May 2011 20:08:26 +0000
Subject: [issue11335] Memory leak after key function failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <1304539706.13.0.932094187731.issue11335@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


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

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

From report at bugs.python.org  Wed May  4 22:32:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2011 20:32:20 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304541140.71.0.839842894709.issue11994@psf.upfronthosting.co.za>


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

GCC 4.4.3 is not the last stable version of the 4.4 branch: try maybe GCC 4.4.6...

Changes of GCC 4.4.4, 4.4.5 and 4.4.6:
http://gcc.gnu.org/gcc-4.4/changes.html#4.4.6

Or try maybe another major version.

----------

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

From report at bugs.python.org  Wed May  4 22:58:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 04 May 2011 20:58:57 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1304531621.3568.11.camel@localhost.localdomain>
Message-ID: <BANLkTi=WW6=Xqv_=JjiFA8UyWVdLKwsoKw@mail.gmail.com>


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

>> - what's current_thread_id ? If it's thread_get_ident (pthread_self),
>> since TID is not guaranteed to be inherited across fork, this won't
>> work
>
> Ouch, then the approach I'm proposing is probably doomed.
>

Well, it works on Linux with NPTL, but I'm not sure at all it holds
for other implementations (pthread_t it's only meaningful within the
same process).
But I'm not sure it's really the "killer" point: PID with linuxthreads
and lock being acquired by a second thread before the main thread
releases it in the child process also look like serious problems.

> Well, this means indeed that *some* locks can be handled, but not all of
> them and not automatically, right?
> Also, how would you propose they be dealt with in practice? How do they
> get registered, and how does the reinitialization happen?

When a lock object is allocated in Modules/threadmodule.c
(PyThread_allocate_lock/newlockobject), add the underlying lock
(self->lock_lock) to a linked list (since it's called with the GIL
held, we don't need to protect the linked list from concurrent
access). Each thread implementation (thread_pthread.h, thread_nt.h)
would provide a new PyThread_reinit_lock function that would do the
right thing (pthread_mutex_destroy/init, sem_destroy/init, etc).
Modules/threadmodule.c would provide a new PyThread_ReInitLocks that
would walk through the linked list and call PyThread_reinit_lock for
each lock.
PyOS_AfterFork would call this PyThread_ReInitLocks right after fork.
This would have the advantage of being consistent with what's already
done to reinit the TLS key and the import lock. So, we guarantee to be
in a consistent and usable state when PyOS_AfterFork returns. Also,
it's somewhat simpler because we're sure that at that point only one
thread is running (once again, no need to protect the linked-list
walk).
I don't think that the performance impact would be noticable (I know
it's O(N) where N is the number of locks), and contrarily to the
automatic approach, this wouldn't penalize every acquire/release.
Of course, this would solve the problem of threading's module locks,
so PyEval_ReInitThreads could be removed, along with threading.py's
_after_fork and _reset_internal_locks.
In short, this would reset every lock held so that they're usable in
the child process, even locks allocated e.g. from
Modules/_io/bufferedio.c.
But this wouldn't allow a lock's state to be inherited across fork for
the main thread (but like I said, I don't think that this makes much
sense anyway, and to my knowledge no implementation makes such a
guarantee - and definitely not POSIX).

----------

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

From report at bugs.python.org  Wed May  4 23:45:12 2011
From: report at bugs.python.org (Robert Xiao)
Date: Wed, 04 May 2011 21:45:12 +0000
Subject: [issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
In-Reply-To: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>
Message-ID: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>


New submission from Robert Xiao <nneonneo at gmail.com>:

On Python 3.2, calling abort() on an ftplib.FTP object will cause an exception:

>>> ftp = ftplib.FTP('localhost')
>>> ftp.abort()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/ftplib.py", line 246, in abort
    self.sock.sendall(line, MSG_OOB)
TypeError: 'str' does not support the buffer interface

The offending line, ftplib.py:246, should be replaced by
self.sock.sendall(line.encode(self.encoding), MSG_OOB)

----------
components: Library (Lib)
messages: 135158
nosy: nneonneo
priority: normal
severity: normal
status: open
title: ftplib.FTP.abort fails with TypeError on Python 3.x
type: crash
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu May  5 00:08:45 2011
From: report at bugs.python.org (alejandro david weil)
Date: Wed, 04 May 2011 22:08:45 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>


New submission from alejandro david weil <tenuki at gmail.com>:

Python's documentation includes 2 source codes for alternate xrange implementations, which, at least in my tests, give unexpected results.

# from file:///usr/share/doc/python2.6-doc/html/library/functions.html#xrange
takewhile(lambda x:x<stop, (start+i*step for i in count()))

and:


# from: http://docs.python.org/library/functions.html?highlight=xrange#xrange
islice(count(start, step), (stop-start+step-1)//step)


I'll attach a file with source code showing that, and propose 3 different versions which seems to work fine. (I've prefer the first one, but python lacks of sign() function).

----------
assignee: docs at python
components: Documentation
files: test_xrange.py
messages: 135159
nosy: docs at python, tenuki
priority: normal
severity: normal
status: open
title: documentation: alternate version of xrange seems to fail.
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21887/test_xrange.py

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

From report at bugs.python.org  Thu May  5 00:14:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 04 May 2011 22:14:50 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1304547290.43.0.365592869244.issue11015@psf.upfronthosting.co.za>


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

Hi all,
IIUIC we are left with issue11015.py3k.testdoc.1.patch) since issue11015.py3k.remove_fcmp.{1,2}.patch has been already applied on default.

I just gave a look to the doc patch and it seems fine (it also applies without any warning on default).

Eli, do you want to expand this patch further (and how :) or do you think it's still the version you want to commit? Can a core devel, then, give this patch a deeper look?

----------

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

From report at bugs.python.org  Thu May  5 01:06:20 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 04 May 2011 23:06:20 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304550380.39.0.0432443143928.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

I am new to the community but hoping to start contributing or at least following issues and learning :) 

I'm looking at bufferediobase_readinto(). What I haven't yet figured out is why .readinto() is (currently) implemented at this layer of the hierarchy. You have to have a raw read buffer available to read from and I'm not sure how one would acquire that from here (without calling .read() or something that has been overridden and knows about the raw buffer).

I feel like bufferediobase_readinto() should return unsupported. Also readinto(), in theory, is lower level than read. if read isn't implemented at this layer why is readinto()?

With a little direction, I would be interested in helping w/a patch.

----------
nosy: +jcon

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

From report at bugs.python.org  Thu May  5 01:09:57 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 04 May 2011 23:09:57 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1304550380.39.0.0432443143928.issue9971@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=xy_AjdX3eaX73t2Tur6jDcWLixA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/4 John O'Connor <report at bugs.python.org>:
>
> John O'Connor <tehjcon at gmail.com> added the comment:
>
> I am new to the community but hoping to start contributing or at least following issues and learning :)
>
> I'm looking at bufferediobase_readinto(). What I haven't yet figured out is why .readinto() is (currently) implemented at this layer of the hierarchy. You have to have a raw read buffer available to read from and I'm not sure how one would acquire that from here (without calling .read() or something that has been overridden and knows about the raw buffer).

Why is that? You can, as the BufferedIOBase implementation does, just
call read() and stick it into the buffer.

>
> I feel like bufferediobase_readinto() should return unsupported. Also readinto(), in theory, is lower level than read. if read isn't implemented at this layer why is readinto()?

To provide a simple implementation for unsophisticated subclasses.

----------

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

From report at bugs.python.org  Thu May  5 01:14:01 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Wed, 04 May 2011 23:14:01 +0000
Subject: [issue8158] Docstring of optparse.OptionParser incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1304550841.44.0.609673011693.issue8158@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Applied patch cleanly. Also the description reads clearly and makes sense.

----------
nosy: +louiscipher

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

From report at bugs.python.org  Thu May  5 01:57:21 2011
From: report at bugs.python.org (Quinn Slack)
Date: Wed, 04 May 2011 23:57:21 +0000
Subject: [issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http,
	and urllib
In-Reply-To: <1303943331.28.0.343800117154.issue11943@psf.upfronthosting.co.za>
Message-ID: <1304553441.72.0.957716968847.issue11943@psf.upfronthosting.co.za>


Quinn Slack <sqs at cs.stanford.edu> added the comment:

I have updated the patch in hg to address the sections marked "TODO" (after I submitted a patch to OpenSSL that they depended on). I'll resubmit a patch here in a ~week addressing that issue and those below, to continue pushing this issue along.

pitrou: Thanks for your feedback.

> - the OpenSSL functions you are using (SSL_get_srp_username etc.) don't seem documented on openssl.org; this makes it harder to do a proper review

Yes...I'll submit some docs to OpenSSL on these functions.

> - what is an "SRP vbase"? is it something standardized, or OpenSSL-specific?
> - if server-side support needs a callback, I think it would be better to let users write their callback in Python, rather than force a hardwired implementation

An SRP "vbase" is OpenSSL's name for the SRP password (verifier) database. I will generalize this interface so that Python callbacks can be provided (in addition to using an OpenSSL verifier database).

> - no need to fill Misc/ACKS and Misc/NEWS by yourself, we can take care of that
> - ssl.wrap_socket() is the legacy API, I would rather add new features only to the SSLContext API

Got it.

----------

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

From report at bugs.python.org  Thu May  5 01:57:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 May 2011 23:57:33 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1304553453.71.0.570303940199.issue11015@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is an improvement that I think should be committed before 3.2.1.
Some comments:

+.. function:: run_doctest(module, verbosity=None)
+   Run :mod:`doctest` on the given *module*.
should be, I believe,
+   Run :func:`doctest.testmod` on the given *module*.
as that is what the function actually does (I check the code).

+   If *verbosity* is :const:`None`, :meth:`doctest` is run with verbosity set
+   to :data:`verbose`.  Otherwise, it is run with verbosity set to
+   :const:`None`.

Should :meth:`doctest` be :func:`testmod` ?
Otherwise the proposed text rewrites

"    If optional argument verbosity is not specified (or is None), pass
    support's belief about verbosity on to doctest.  Else doctest's
    usual behavior is used (it searches sys.argv for -v)."

The problem with the rewrite is that the keyword param of testmod is 'verbose', not 'verbosity'. 'Verbosity' is a dummy name used to either pass support.verbose to verbose, or not. So testmod is, in net effect, run with verbose=verbose or verbose=None. My attempt to explain a bad design (with probable markup errors):

"If *verbosity* is :const:`None`, :func:`testmod` is run with verbose set to :data:`support.verbose`, which is set by :func:`regrtest`. Otherwise, it is run with verbose set to :const:`None` and subsequently replaced by :code:`'-v' in sys.argv`."


+.. function:: temp_umask(umask)
+
+   A context manager that temporarily sets the process umask to the
+   given value.

"sets the process umask to *umask*." ?


+.. function:: find_unused_port(family=socket.AF_INET, socktype=socket.SOCK_STREAM)

+   Either this method or :func:`bind_port` should be used for any tests
+   where a server socket needs to be bound to a particular port for the
+   duration of the test.
+   Which one to use depends on whether the calling code is creating a python
+   socket, or if an unused port needs to be provided in a constructor
+   or passed to an external program (i.e. the ``-accept`` argument to
+   openssl's s_server mode). 

This is copied from the doc string but does really tell me which to use in which of the two situations.

Other additions look OK to me. Some copied docstrings (or comments). Some are new. Support.py could also use a patch to add missing docstings (and turn a couple of comments into docstrings).

----------

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

From report at bugs.python.org  Thu May  5 02:35:37 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 05 May 2011 00:35:37 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304555737.32.0.0606655470844.issue9971@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Looking at this again, I agree with John.  For BufferedIOBase, read() is abstract while readinto() is concrete.  That seems backward, and, indeed, it's the opposite of RawIOBase, where readinto() is abstract and read() is concrete.

Unfortunately, this code has shipped, so changing which methods are abstract may not be practical.  On the other hand, the documentation doesn't mention which methods are abstract versus concrete.

All of that said, we can freely change the C implementation of BufferedReader which is a concrete class.  That would allow us to cut out the extra allocoations/deallocations, even if we can't clean up the abstract vs concrete method issue.  Basically, this would require greatly expanding buffered_readinto() in bufferedio.c to use _bufferedreader_raw_read() and related functions.

As I think about this more... I'm not sure how much performance there is to gain here in practice.  It seems like any time I'd want to use readinto(), it's because I want to do my own buffering, in which case why would I use a BufferedReader?  I'm thinking that BufferedIOBase only provides a readinto() method for completeness, so it can be used as a drop-in replacement for an unbuffered file object.

----------

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

From report at bugs.python.org  Thu May  5 03:09:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2011 01:09:25 +0000
Subject: [issue8158] Docstring of optparse.OptionParser incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <E1QHn4F-0004gQ-DN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c13d2552eb51 by R David Murray in branch '2.7':
#8158: add missing 'description' description to optparse docstring.
http://hg.python.org/cpython/rev/c13d2552eb51

New changeset f559b88bcaa0 by R David Murray in branch '3.1':
#8158: add missing 'description' description to optparse docstring.
http://hg.python.org/cpython/rev/f559b88bcaa0

New changeset b4b0a1458638 by R David Murray in branch '3.2':
Merge #8158: add missing 'description' description to optparse docstring.
http://hg.python.org/cpython/rev/b4b0a1458638

New changeset 2a403afc4a76 by R David Murray in branch 'default':
Merge #8158: add missing 'description' description to optparse docstring.
http://hg.python.org/cpython/rev/2a403afc4a76

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

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

From report at bugs.python.org  Thu May  5 03:10:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 01:10:23 +0000
Subject: [issue8158] Docstring of optparse.OptionParser incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1304557823.89.0.631121825959.issue8158@psf.upfronthosting.co.za>


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

Thanks everyone.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Thu May  5 03:52:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 01:52:29 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304560349.32.0.402521737584.issue11935@psf.upfronthosting.co.za>


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

Not all system mail spools are mode 1777.  Mutt needs to be setgid mail on systems that aren't, if I understand correctly.  Making a python program setgid mail is a bit more of security issue than making a well-tested C program setgid, since it is easier to break out of the box in a python program.

I'm pretty sure that the shell does not parse the mbox when it produces its 'you have new mail' message.  I believe it just looks at the mtime/atime.

mailbox is an mbox manipulation program, not a mail delivery agent.  If you are using it to write a mail delivery agent, I think perhaps the mtime setting code belongs in your application, not the mailbox module.

----------

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

From report at bugs.python.org  Thu May  5 04:27:20 2011
From: report at bugs.python.org (Ben Morgan)
Date: Thu, 05 May 2011 02:27:20 +0000
Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors
In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za>
Message-ID: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za>


New submission from Ben Morgan <benpmorgan at gmail.com>:

PyZipFile.writepy gives internal error on syntax errors in files it processes.

For example, in the attached test case:
Traceback (most recent call last):
  File "C:\tfs\SDKS\python\Python32\lib\py_compile.py", line 119, in compile
    optimize=optimize)
  File "test_zipfile_error_bad_syntax.py", line 1
    syntax error
               ^
SyntaxError: invalid syntax

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1393, in _compile
    py_compile.compile(file, doraise=True, optimize=optimize)
  File "C:\tfs\SDKS\python\Python32\lib\py_compile.py", line 123, in compile
    raise py_exc
py_compile.PyCompileError:   File "test_zipfile_error_bad_syntax.py", line 1
    syntax error
               ^
SyntaxError: invalid syntax


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test_zipfile_error.py", line 7, in <module>
    pzf.writepy(PYFILE)
  File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1376, in writepy
    fname, arcname = self._get_codename(pathname[0:-3], basename)
  File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1428, in _get_codename

    if _compile(file_py):
  File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1395, in _compile
    print(err.msg)
NameError: global name 'err' is not defined

Around zipfile.py:1395 
in PyZipFile._get_codename _compile
            try:
                py_compile.compile(file, doraise=True, optimize=optimize)
            except py_compile.PyCompileError as error:
                print(err.msg)
                return False

The print should be printing error.msg not err.msg

----------
files: test_zipfile_error.py
messages: 135170
nosy: Ben.Morgan
priority: normal
severity: normal
status: open
title: PyZipFile.writepy gives internal error on syntax errors
type: behavior
Added file: http://bugs.python.org/file21888/test_zipfile_error.py

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

From report at bugs.python.org  Thu May  5 04:28:06 2011
From: report at bugs.python.org (Ben Morgan)
Date: Thu, 05 May 2011 02:28:06 +0000
Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors
In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za>
Message-ID: <1304562486.4.0.48051623202.issue12004@psf.upfronthosting.co.za>


Changes by Ben Morgan <benpmorgan at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21889/pyzipfile-error.patch

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

From report at bugs.python.org  Thu May  5 05:19:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 05 May 2011 03:19:38 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1304547290.43.0.365592869244.issue11015@psf.upfronthosting.co.za>
Message-ID: <BANLkTikERoMK7VxMLyf=7msrhzA3RvRKjQ@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> Eli, do you want to expand this patch further (and how :) or do you think
> it's still the version you want to commit? Can a core devel, then, give this
> patch a deeper look?
>

I will review this again in a couple of days and will commit.

----------
Added file: http://bugs.python.org/file21890/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________
-------------- 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;">
Eli, do you want to expand this patch further (and how :) or do you think it&#39;s still the version you want to commit? Can a core devel, then, give this patch a deeper look?<br></blockquote></div><br>I will review this again in a couple of days and will commit.<br>

<br></div>

From report at bugs.python.org  Thu May  5 06:10:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 May 2011 04:10:32 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1304568632.75.0.776136664361.issue11015@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21890/unnamed

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

From report at bugs.python.org  Thu May  5 06:46:07 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 May 2011 04:46:07 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304570767.76.0.0677059449481.issue9971@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't see the problem. You're free to override readinto() and read() in subclasses. readinto() is just implemented in BufferedIOBase as a convenience.

----------

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

From report at bugs.python.org  Thu May  5 07:41:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 May 2011 05:41:46 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <BANLkTi=WW6=Xqv_=JjiFA8UyWVdLKwsoKw@mail.gmail.com>
Message-ID: <BANLkTinHvA-re2T-d==BmVp+_E-0t8D0Pw@mail.gmail.com>


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

Please disregard my comment on PyEval_ReInitThreads and _after_fork:
it will of course still be necessary, because it does much more than
just reinitializing locks (e.g. stop threads).
Also, note that both approaches don't handle synchronization
primitives other  than bare Lock and RLock. For example, Condition and
Event used in the threading module wouldn't be reset automatically:
that's maybe something that could be handled by Gregory's atfork
mechanism.

----------

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

From report at bugs.python.org  Thu May  5 09:10:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 05 May 2011 07:10:24 +0000
Subject: [issue11962] Buildbot reliability
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304579424.71.0.878130898258.issue11962@psf.upfronthosting.co.za>


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

The FreeBSD bot had these error messages in the log files:

1) kernel: swap_pager: indefinite wait buffer: device
2) Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.p
v_entry_max sysctl.


I set up the bot from scratch with these changes:

a) Use swap partition (2GB) instead of swap file (2 GB).

b) Use these sysctls:

     kern.ipc.shm_use_phys=1
     vm.pmap.shpgperproc=4096
     vm.pmap.pv_entry_max=16777216

c) Use self-compiled Python2.7 instead of the system Python2.6.


Let's see how that works out. Error 1) is bad, perhaps FreeBSD
does not play well with the qcow2 file system under high load.

----------

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

From report at bugs.python.org  Thu May  5 09:36:06 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 05 May 2011 07:36:06 +0000
Subject: [issue11962] Buildbot reliability
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304580966.09.0.228182098028.issue11962@psf.upfronthosting.co.za>


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

On second thought, I don't want to debug possible qcow2 issues, so
I made another change:

d) Use raw format for the image.

----------

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

From report at bugs.python.org  Thu May  5 10:35:19 2011
From: report at bugs.python.org (Daniel Albeseder)
Date: Thu, 05 May 2011 08:35:19 +0000
Subject: [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>


New submission from Daniel Albeseder <kotan at gmx.at>:

I know that the modulo operation for negative values is not well defined, but I would at least expect that the result is the same no matter if you use ints, floats or decimals. However Decimal seem to behave else than the builtin types.

Python 3.1.2 (release31-maint, Sep 17 2010, 20:27:33) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> -3 % 5
2
>>> -3. % 5.
2.0
>>> Decimal(-3) % Decimal (5)
Decimal('-3')
>>> 

I could reproduce the same for python 2.6.6.

----------
components: Library (Lib)
messages: 135176
nosy: Kotan
priority: normal
severity: normal
status: open
title: modulo result of Decimal differs from float/int
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Thu May  5 11:31:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 09:31:55 +0000
Subject: [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1304587915.8.0.727310708015.issue12005@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May  5 12:03:43 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Thu, 05 May 2011 10:03:43 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>


New submission from Erik Cederstrand <ec at 1calendar.dk>:

Python is via datetime.isocalendar() able to produce the ISO week number and ISO weekday from a given date. But it is not possible to do the reverse; calculate the date from a year, ISO week number and weekday.

libc strptime()/strftime() mentions a %V and %u directive which does this, i.e. Monday in ISO week 22 of the year 2011:

   datetime.strptime('2011221', '%Y%V%u')

returning 2011-05-30 and

   datetime.strptime('2011227', '%Y%V%u')

returning 2011-06-05


libc (on FreeBSD) has this to say:

%V is replaced by the week number of the year (Monday as the first day
   of the week) as a decimal number (01-53).  If the week containing
   January 1 has four or more days in the new year, then it is week 1;
   otherwise it is the last week of the previous year, and the next
   week is week 1.

%u is replaced by the weekday (Monday as the first day of the week) as
   a decimal number (1-7).

----------
components: Library (Lib)
messages: 135177
nosy: Erik.Cederstrand
priority: normal
severity: normal
status: open
title: strptime should implement %V or %u directive from libc
type: feature request

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

From report at bugs.python.org  Thu May  5 12:17:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 10:17:54 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1304590674.23.0.198180171749.issue11015@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I left a few comments on rietveld for the testdoc and remove_fcmp patches.
Unless I'm missing something, assertEqual works just fine in all the places where fcmp was used, so there's no need to use assertAlmostEqual.

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

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

From report at bugs.python.org  Thu May  5 12:20:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 10:20:07 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1304590807.86.0.847329072741.issue12006@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May  5 12:25:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 10:25:28 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1304591128.9.0.248603370606.issue12003@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, rhettinger

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

From report at bugs.python.org  Thu May  5 12:34:13 2011
From: report at bugs.python.org (svilen dobrev)
Date: Thu, 05 May 2011 10:34:13 +0000
Subject: [issue1046092] HTMLParser fix to accept malformed tag attributes
Message-ID: <1304591653.11.0.170313338629.issue1046092@psf.upfronthosting.co.za>


svilen dobrev <az at svilendobrev.com> added the comment:

this seems to eat too much into data and gets past endpos of the chunk processed, and parser gets confused and treats any subsequent stuff as data. i didn't think out how to fix the regexp as such, but instead limited its span to :endpos so it doesnot eat too much. 
seems to happen with unquoted attributes.

----------
nosy: +svilend
Added file: http://bugs.python.org/file21891/html.parser.diff

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

From report at bugs.python.org  Thu May  5 12:35:02 2011
From: report at bugs.python.org (svilen dobrev)
Date: Thu, 05 May 2011 10:35:02 +0000
Subject: [issue1046092] HTMLParser fix to accept malformed tag attributes
Message-ID: <1304591702.0.0.275883607174.issue1046092@psf.upfronthosting.co.za>


Changes by svilen dobrev <az at svilendobrev.com>:


Added file: http://bugs.python.org/file21892/test-htmlparser-attrs.py

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

From report at bugs.python.org  Thu May  5 12:44:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 10:44:17 +0000
Subject: [issue1046092] HTMLParser fix to accept malformed tag attributes
Message-ID: <1304592257.1.0.140232775529.issue1046092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This issue is closed, so it's better if you create a new issue.
Even better if you can attach a patch that adds a testcase to Lib/test/test_htmlparser.py

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

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

From report at bugs.python.org  Thu May  5 12:46:06 2011
From: report at bugs.python.org (Jakob Aga)
Date: Thu, 05 May 2011 10:46:06 +0000
Subject: [issue12007] Console commands won't work
In-Reply-To: <1304592366.23.0.247868928288.issue12007@psf.upfronthosting.co.za>
Message-ID: <1304592366.23.0.247868928288.issue12007@psf.upfronthosting.co.za>


New submission from Jakob Aga <jake_mcaga at yahoo.com>:

[PCLOS KDE 2010.12] Console commands (in Konsole & Yakuake) won't work in Python 3.2. Like ctrl+l for clearing the screen, arrow keys up & down for scrolling through previous python commands. Instead I get e.g. ^L (ctrl+l) and ^[[A (arrow up) on the interpreter line.
At first I looked through Synaptic (reload etc.), then I tried compiling the 3.2 version - and built it with 'luck' (yay:)).
The interpreter 'works' by itself though. It's just that I miss doing the usual console stuff. 3.2 is installed side by side with Python 2.6, and I haven't had any problems with Python 2.x
I've posted this problem on the forums of PCLOS, but no one can answer. Hopefully someone here can...?

----------
components: IO
messages: 135181
nosy: jake_mcaga
priority: normal
severity: normal
status: open
title: Console commands won't work
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu May  5 12:47:28 2011
From: report at bugs.python.org (svilen dobrev)
Date: Thu, 05 May 2011 10:47:28 +0000
Subject: [issue12008] HtmlParser non-strict goes wrong with unquoted attributes
In-Reply-To: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za>
Message-ID: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za>


New submission from svilen dobrev <az at svilendobrev.com>:

nonstrict mode seems to eat too much into data and gets past endpos of the chunk processed, and parser gets confused and treats any subsequent stuff as data. i didn't think out how to fix the regexp as such, but instead limited its span to :endpos so it doesnot eat too much. 
seems to happen with unquoted attributes.

----------
files: html.parser.diff
keywords: patch
messages: 135182
nosy: svilend
priority: normal
severity: normal
status: open
title: HtmlParser non-strict goes wrong with unquoted attributes
Added file: http://bugs.python.org/file21893/html.parser.diff

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

From report at bugs.python.org  Thu May  5 12:48:12 2011
From: report at bugs.python.org (svilen dobrev)
Date: Thu, 05 May 2011 10:48:12 +0000
Subject: [issue12008] HtmlParser non-strict goes wrong with unquoted attributes
In-Reply-To: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za>
Message-ID: <1304592492.7.0.0325598785822.issue12008@psf.upfronthosting.co.za>


Changes by svilen dobrev <az at svilendobrev.com>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.2
Added file: http://bugs.python.org/file21894/test-htmlparser-attrs.py

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

From report at bugs.python.org  Thu May  5 12:51:49 2011
From: report at bugs.python.org (svilen dobrev)
Date: Thu, 05 May 2011 10:51:49 +0000
Subject: [issue12008] HtmlParser non-strict goes wrong with unquoted attributes
In-Reply-To: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za>
Message-ID: <1304592709.21.0.509221667993.issue12008@psf.upfronthosting.co.za>


svilen dobrev <az at svilendobrev.com> added the comment:

(the nonstrict regexp came with Issue1046092)

----------

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

From report at bugs.python.org  Thu May  5 12:54:12 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 10:54:12 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304560349.32.0.402521737584.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110505105402.GA79405@sherwood.local>


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

On Thu,  5 May 2011 03:52:29 +0200, R. David Murray wrote:
> [..] the shell [..] I believe it just looks at the mtime/atime.

/* check_mail () is useful for more than just checking mail.  Since it has
   the paranoids dream ability of telling you when someone has read your
   mail, it can just as easily be used to tell you when someones .profile
   file has been read, thus letting one know when someone else has logged
   in.  Pretty good, huh? */

          /* If the user has just run a program which manipulates the
             mail file, then don't bother explaining that the mail
             file has been manipulated.  Since some systems don't change
             the access time to be equal to the modification time when
             the mail in the file is manipulated, check the size also.  If
             the file has not grown, continue. */

         /* If the mod time is later than the access time and the file
             has grown, note the fact that this is *new* mail. */

> Not all system mail spools are mode 1777.  Mutt needs to be
> setgid mail on systems that aren't, if I understand correctly.
> Making a python program setgid mail is a bit more of security
> issue than making a well-tested C program setgid, since it is
> easier to break out of the box in a python program.

Ok, maybe set-group-ID on /var/mail isn't even necessary;
    0 drwxrwxx-x    3 root      mail       102  5 May 11:30 mail
is enough as long as
    $ groups $USER
states you are member of group mail.  On my system mailbox.py
doesn't have any problems with modifying the mail directory.
If this is not true on your box go and stress your admin, he's not
worth his money - is he?
I.e., whereas it is possible to rewrite mailbox.py to handle issue
#7359 i would not do so because it is unnecessary on correctly
setup boxes.  Maybe mailbox.py has used so much copy-and-paste
from mutt(1)'s mbox.c because that code works well for many years.
And Jason seems to work as root all of the time.

> mailbox is an mbox manipulation program, not a mail delivery
> agent.  If you are using it to write a mail delivery agent,
> I think perhaps the mtime setting code belongs in your
> application, not the mailbox module.

I really don't understand your point now.
Of course the standart is soft like butter in that it seems to
assume that the spool mailbox is then locally processed and
truncated to zero length, so that "mailbox has grown==new mail
arrived", whereas it is also possible to use that spool file as
a real local mailbox, including resorting, partial deletion etc..

This issue is about fixing mailbox.py to adhere MMDF and MBOX
standarts, which is what the patch implements.
This patch works for me locally in that mutt(1) will mention that
new mail has arrived in the boxes.

The patch uses a safe approach by dating back the access time
instead of pointing modification time into the future, which
however will make the patch fail on Pear OS X if the mailbox is on
HFS, case sensitive, because that is buggy and *always* updates
atime; maybe this is because Apple only provides a shallow wrapper
around UFS to integrate that in the Microkernel/IOKit structure,
just in case HFS, case sensitive is really UFS, but i'm guessing
in all directions here.  I would not adjust the patch to fix this,
but the problem exists and it has been noted in this issue.

--
Steffen
sdaoden at gmail.com

----------

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

From report at bugs.python.org  Thu May  5 12:58:01 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 10:58:01 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304560349.32.0.402521737584.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110505105753.GB79405@sherwood.local>


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

On Thu,  5 May 2011 03:52:29 +0200, R. David Murray wrote:
> [..] the shell [..] I believe it just looks at the mtime/atime.

   Pretty good, huh?

Mr. Mojo says:

    Prowd to be a part of this number.
    Successful hills are here to stay.
    Everything must be this way.

----------

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

From report at bugs.python.org  Thu May  5 13:13:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 11:13:31 +0000
Subject: [issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
In-Reply-To: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>
Message-ID: <1304594011.4.0.228349182292.issue12002@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, giampaolo.rodola

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

From report at bugs.python.org  Thu May  5 13:22:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2011 11:22:10 +0000
Subject: [issue11997] One typo in Doc/c-api/init.rst
In-Reply-To: <1304502837.0.0.265474702081.issue11997@psf.upfronthosting.co.za>
Message-ID: <E1QHwdF-0007NC-2D@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 76a2354aa427 by Ezio Melotti in branch '2.7':
#11997: fix typo in init.rst.
http://hg.python.org/cpython/rev/76a2354aa427

New changeset 3aa51217492c by Ezio Melotti in branch '3.1':
#11997: fix typo in init.rst.
http://hg.python.org/cpython/rev/3aa51217492c

New changeset 5a2d42a8c1ab by Ezio Melotti in branch '3.2':
#11997: merge with 3.1.
http://hg.python.org/cpython/rev/5a2d42a8c1ab

New changeset 7c9717836c28 by Ezio Melotti in branch 'default':
#11997: merge with 3.2.
http://hg.python.org/cpython/rev/7c9717836c28

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

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

From report at bugs.python.org  Thu May  5 13:23:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 11:23:05 +0000
Subject: [issue11997] One typo in Doc/c-api/init.rst
In-Reply-To: <1304502837.0.0.265474702081.issue11997@psf.upfronthosting.co.za>
Message-ID: <1304594585.09.0.0189153819506.issue11997@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu May  5 13:36:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 May 2011 11:36:42 +0000
Subject: [issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr
In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>
Message-ID: <1304595402.29.0.0663473623776.issue11981@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you prove that the second one is useless (did it cause you any problem or did you just find it reading the source)?
There might be reasons why there are two calls to fp.tell() (e.g. the result is different in the two places and/or zinfo.header_offset is read/changed somewhere else between the two calls).

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

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

From report at bugs.python.org  Thu May  5 13:37:40 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 05 May 2011 11:37:40 +0000
Subject: [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1304595460.03.0.937284964697.issue12005@psf.upfronthosting.co.za>


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

I believe that this was a deliberate design decision, though now that I look it seems it's not well documented.  That should probably be fixed, so I see this as a documentation issue.

More details:

The specification on which the decimal module is based requires that there be a 'remainder' operation with the semantics of Decimal's '%' operation (i.e., the result of x % y has the sign of x).  However, the specification doesn't say anything about how the prescribed operations should map to language constructs.

So the choice was between (1) leaving '%' for Decimal objects unimplemented, and providing a separate 'remainder' method, or (2) mapping '%' to Decimal's remainder operation, and accepting the slight mismatch between the '%' semantics for float and Decimal.

Perhaps the wrong choice was made.  But it's there now, and to me it's not so obviously wrong that it's worth the upheaval of deprecating '%' for Decimal objects.

Of course there's a third choice, which is to implement the float % semantics for the Decimal type;  however, this is outside the scope of the specification---none of the specified operations matches this behaviour, and I'd oppose the addition of such an operation to the Decimal module.  There's a strong sense in which Decimal's % is a more natural operation for floating-point types than float's %.  (For one thing, it's exact in many circumstances, while float's % suffers from surprising results with negative operands.)

Reclassifying as a documentation issue.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Thu May  5 13:42:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 11:42:28 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304595748.98.0.796340638276.issue11935@psf.upfronthosting.co.za>


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

Yes if you are a member of group mail you would not need setgid mail, obviously.

The problem report in question was submitted by one of the Debian maintainers, so I have to believe that the system in question was not misconfigured.  This part of the discussion should move to that issue, I think.  I guess I was wrong to link them :)

So, if the mailbox code is imitating mutt (and it may well be, the bulk of it was written as a summer of code project in 2005), what does mutt do in the case you are talking about?

----------

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

From report at bugs.python.org  Thu May  5 13:42:54 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 05 May 2011 11:42:54 +0000
Subject: [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1304595774.27.0.563457000415.issue12005@psf.upfronthosting.co.za>


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

The doc change should also note that // and divmod suffer from a similar mismatch:

>>> Decimal(-2) // Decimal(3)
Decimal('-0')
>>> -2 // 3
-1
>>> -2.0 // 3
-1.0

However, the invariant that x = x // y * y + x % y is retained, as it should be.

----------

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

From report at bugs.python.org  Thu May  5 14:08:34 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 May 2011 12:08:34 +0000
Subject: [issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
In-Reply-To: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>
Message-ID: <1304597314.67.0.566632040372.issue12002@psf.upfronthosting.co.za>


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


----------
assignee:  -> giampaolo.rodola

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

From report at bugs.python.org  Thu May  5 14:11:43 2011
From: report at bugs.python.org (Johan Euphrosine)
Date: Thu, 05 May 2011 12:11:43 +0000
Subject: [issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr
In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>
Message-ID: <1304597503.74.0.837823439154.issue11981@psf.upfronthosting.co.za>


Johan Euphrosine <proppy at google.com> added the comment:

I just find it while reading the source, for fixing #11980

zinfo.header_offset is only read in self._write_check, and it seems to me that no file operation are performed on self.fp between the two call. So I can't see see how it could different.

Also the tests suite still pass after removing the second one :)

Let me know if you want me to do more investigation.

----------

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

From report at bugs.python.org  Thu May  5 14:19:59 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2011 12:19:59 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1304597999.24.0.314455309507.issue10775@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/issue10775>
_______________________________________

From report at bugs.python.org  Thu May  5 14:20:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2011 12:20:50 +0000
Subject: [issue11690] Devguide: Add "communication" FAQ
In-Reply-To: <1301188192.33.0.9529618781.issue11690@psf.upfronthosting.co.za>
Message-ID: <1304598050.14.0.209661602979.issue11690@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ncoghlan

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

From report at bugs.python.org  Thu May  5 14:23:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2011 12:23:07 +0000
Subject: [issue11647] function decorated with a context manager can only be
	invoked once
In-Reply-To: <1300845878.3.0.475491224846.issue11647@psf.upfronthosting.co.za>
Message-ID: <1304598187.13.0.117635970822.issue11647@psf.upfronthosting.co.za>


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


----------
assignee:  -> ncoghlan
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May  5 14:33:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 12:33:46 +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: <1304598826.31.0.323770512148.issue11277@psf.upfronthosting.co.za>


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

@sdaoden(, @pitrou): Antoine proposes to skip the zlib "big buffer" (1 GB) test on 32 bits system. What do you think?

On 64 bits system, we check a buffer of 2 GB-1 byte (0x7FFFFFFF bytes). Is the test useful or not? What do we test?

Can you check if the test crashs on Mac OS X on a 32 bits system (1 GB buffer) if you disable F_FULLFSYNC in mmapmodule.c? Same question on a 64 bits system (2 GB-1 byte buffer)?

The most important test if to test crc32 & adler32 with a buffer bigger than 4 GB, but we cannot write such test in Python 2.7 because the zlib module stores buffer sizes into int variables. So the "big buffer" test of Python 2.7 test_zlib is maybe just useful (on 32 and 64 bits). Can we just remove the test?

----------

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

From report at bugs.python.org  Thu May  5 14:41:55 2011
From: report at bugs.python.org (Johan Euphrosine)
Date: Thu, 05 May 2011 12:41:55 +0000
Subject: [issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr
In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>
Message-ID: <1304599315.04.0.652927874809.issue11981@psf.upfronthosting.co.za>


Johan Euphrosine <proppy at google.com> added the comment:

Here is a log that shows zinfo.header_offset value after each .tell() when running test_zipfile

----------
Added file: http://bugs.python.org/file21895/zinfo.header_offset.log

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

From report at bugs.python.org  Thu May  5 14:49:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 12:49:48 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304599788.9.0.0240732234383.issue10496@psf.upfronthosting.co.za>


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

> If the user base cannot be calculated, paths
> starting with ~ should not exist or be used at all in this context.

It's not "~" but "{userbase}" substitution variable.

Here is a new patch implementing this idea: don't create the variables using the user directory if the user doesn't exist (if we cannot get the user directory). I didn't test distutils, I just try to start Python (it does work using bug.c).

----------
Added file: http://bugs.python.org/file21896/nonexistent_user.patch

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

From report at bugs.python.org  Thu May  5 15:25:50 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Thu, 05 May 2011 13:25:50 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>


New submission from Ruslan Mstoi <rmstoi at gmail.com>:

It seems recent patch from Issue 10464 has introduced problems into
one line comment handling of netrc module.


Problem 1:

If there is a line starting with a comment sign the
following traceback is shown:

Traceback (most recent call last):
  File "/usr/lib/python2.7/netrc.py", line 32, in __init__
    self._parse(file, fp)
  File "/usr/lib/python2.7/netrc.py", line 90, in _parse
    file, lexer.lineno)
netrc.NetrcParseError: bad follower token '#' (./.netrc, line 3)


This can be fixed by modifying netrc.py like this:
71c71
<                 if (tt=='' or tt == 'machine' or
---
>                 if (tt=='' or tt == 'machine' or tt[0] == "#" or

Problem 2:

Now with the patch above it seems to work as long as there are
no comment lines like these:

a) with only pound sign:
#

b) with a pound sign followed by text without any space in between
#comment

If comment line like that is followed by netrc token that token
is consumed by fp.readline(). For example, if netrc file has
these contents:

<<<

machine host.domain.com login username password something

# comment1
machine host2.domain.com login username2 password something2

#comment2
machine host3.domain.com login username3 password something3

#
machine host4.domain.com login username4 password something4
>>>

netrc object will have entries only for host3 and host4.

----------
messages: 135196
nosy: rmstoi
priority: normal
severity: normal
status: open
title: netrc module crashes if netrc file has comment lines
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu May  5 15:32:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 13:32:46 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304602366.12.0.678241672733.issue11873@psf.upfronthosting.co.za>


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

Ah ah, this bug is funny :-) test_regexp doesn't fail because of a race condition or a file system issue, but because of the regex!

The regex "ba.*" is applied on the fullname, not only on the basename. If the temporary contains "ba", the test fails :-) Replace tempfile.mkdtemp() by tempfile.mkdtemp(prefix='bar') in CommandLineTests.setUp() to always reproduce this bug.

----------

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

From report at bugs.python.org  Thu May  5 15:34:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 13:34:13 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304602453.13.0.606744262937.issue11873@psf.upfronthosting.co.za>


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

Ah ah, this bug is funny :-) test_regexp doesn't fail because of a race condition or a file system issue, but because of the regex!

The regex "ba.*" is applied on the fullname, not only on the basename. If the temporary contains "ba", the test fails :-) Replace tempfile.mkdtemp() by tempfile.mkdtemp(prefix='bar') in CommandLineTests.setUp() to always reproduce this bug.

----------

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

From report at bugs.python.org  Thu May  5 15:34:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 13:34: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: <1304602482.28.0.0250575521055.issue11873@psf.upfronthosting.co.za>


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

Ah ah, this bug is funny :-) test_regexp doesn't fail because of a race condition or a file system issue, but because of the regex!

The regex "ba.*" is applied on the fullname, not only on the basename. If the temporary contains "ba", the test fails :-) Replace tempfile.mkdtemp() by tempfile.mkdtemp(prefix='bar') in CommandLineTests.setUp() to always reproduce this bug.

----------

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

From report at bugs.python.org  Thu May  5 15:34:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 13:34:58 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304602498.88.0.188657273576.issue11873@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg135199

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

From report at bugs.python.org  Thu May  5 15:35:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 13:35:36 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304602536.11.0.463347192289.issue12000@psf.upfronthosting.co.za>


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

Are you sure about "if not san and not dnsnames"? It is even more restrictive than the currently condition. "if not dnsnames" looks like it would fit the bill better.

Also, better if you can provide a complete patch, including additional test(s) in Lib/test/test_ssl.py.
(see http://docs.python.org/devguide/runtests.html if you want information about running/writing tests)

----------
nosy: +pitrou
versions:  -Python 3.4

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

From report at bugs.python.org  Thu May  5 15:45:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 13:45:12 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304603112.36.0.196730856908.issue11888@psf.upfronthosting.co.za>


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

Updated patch to use the system log2() if it is available. The test pass with the system log2() on Linux (Debian Sid, eglibc 2.11.2).

----------
Added file: http://bugs.python.org/file21897/issue11888-2.patch

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

From report at bugs.python.org  Thu May  5 15:53:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 May 2011 13:53:01 +0000
Subject: [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1304603581.02.0.935540192425.issue12005@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Thu May  5 15:58:07 2011
From: report at bugs.python.org (Chris Rose)
Date: Thu, 05 May 2011 13:58:07 +0000
Subject: [issue11965] Simplify context manager in os.popen
In-Reply-To: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>
Message-ID: <1304603887.41.0.868443619493.issue11965@psf.upfronthosting.co.za>


Chris Rose <offby1 at offby1.net> added the comment:

I'm pretty sure that the os._wrap_close wrapper is not the same thing as the Popen context manager. I don't think it's useful to try refactor this. As Antoine points out, the current wrapper serves a very different purpose.

----------
nosy: +offby1

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

From report at bugs.python.org  Thu May  5 16:01:53 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 14:01:53 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1304598826.31.0.323770512148.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110505140143.GA54119@sherwood.local>


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

@haypo: trouble, trouble on the dev-list, as i've seen currently.
Sorry, sorry.  (Cannot subscribe, my DynIP's are often blacklisted ;)
Of course my comments were completely wrong, as Ethan has pointed
out correctly.

This is all s**t.  These are mmap(2) related issues and should be
tested in Lib/test/test_mmap.py.  However that does not use
    with open:
        create sparse file
        materialize
yet so that the Pear OS X sparsefile bug doesn't show up.  In fact
it doesn't do a full beam-me-up test at all yet?

> Is the test useful or not? What do we test?

We do test that mmap.mmap materializes a buffer which can be
accessed (readonly) from [0]..[len-1].
And that the checksums that zlib produces for that buffer are
correct.  Unfortunately we cannot test 0x80000000+ no more because
Python prevents that such a buffer can be used - that's a shame.
Maybe we could test 0x7FFFFFFF*2 aka 0xfffffffe in two iterations.

> Can you check if the test crashs on Mac OS X on a 32 bits system
> (1 GB buffer) if you disable F_FULLFSYNC in mmapmodule.c? Same
> question on a 64 bits system (2 GB-1 byte buffer)?

Aeh - F_FULLFSYNC was not yet committed at that time in 2.7.

> Can we just remove the test?

If i - choke! - need to write tests, i try to catch corner cases.
The corner cases would be 0,MAX_LEN(-1) and some (rather pseudo)
random values around these and maybe some in the middle.
(Plus some invalid inputs.)

Can we remove it?  I would keep it, Apple is preparing the next
major release (uname -a yet states 10.7.0 even though it's
10.6.7), and maybe then mmap() will fail for 0xDEADBEEF.
Who will be the one which detects that otherwise??

----------

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

From report at bugs.python.org  Thu May  5 16:04:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2011 14:04:04 +0000
Subject: [issue11647] function decorated with a context manager can only be
	invoked once
In-Reply-To: <1300845878.3.0.475491224846.issue11647@psf.upfronthosting.co.za>
Message-ID: <E1QHz9u-0005ht-8P@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e4ba097123f6 by Nick Coghlan in branch '3.2':
Issue #11647: allow contextmanager objects to be used as decorators as described in the docs. Initial patch by Ysj Ray.
http://hg.python.org/cpython/rev/e4ba097123f6

New changeset b23d1df7e47e by Nick Coghlan in branch 'default':
Merge #11647 update from 3.2
http://hg.python.org/cpython/rev/b23d1df7e47e

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

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

From report at bugs.python.org  Thu May  5 16:04:09 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 14:04:09 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304604249.46.0.403265014755.issue12000@psf.upfronthosting.co.za>


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

P.S.: if you're really right ('have those RFC's, but didn't read
them yet), you could also open an issue for Mercurial at
http://mercurial.selenic.com/bts - i think those guys do the very
same.

Thanks, Steffen!

----------
nosy: +sdaoden

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

From report at bugs.python.org  Thu May  5 16:09:21 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2011 14:09:21 +0000
Subject: [issue11647] function decorated with a context manager can only be
	invoked once
In-Reply-To: <1300845878.3.0.475491224846.issue11647@psf.upfronthosting.co.za>
Message-ID: <1304604561.23.0.938691561261.issue11647@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The core bug has been fixed for 3.2.1 and forward ported to 3.3.

I credited the patch to "Ysj Ray" in ACKS and NEWS, let me know if you'd prefer a different attribution.

Leaving the issue open for now, since _recreate_cm() should be renamed and documented for 3.3 (but I haven't settled on a public name at this point - recreate_cm() isn't quite right for the public API, as reusable CMs aren't actually recreated by the method)

----------
versions:  -Python 3.2

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

From report at bugs.python.org  Thu May  5 16:28:17 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 14:28:17 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304595748.98.0.796340638276.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110505142808.GA70318@sherwood.local>


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

On Thu,  5 May 2011 13:42:29 +0200, R. David Murray wrote:
> what does mutt do in the case you are talking about?

    16 -rwxr-s---  1 steffen  mail  14832 23 Jan 19:13 usr/bin/mutt_bitlock
    set bitlock_program="~/usr/bin/mutt_bitlock -p"

I see.  Unfortunately the world is not even almost perfect.
So should f?truncate(2) be used if the resulting file is empty?

> what does mutt do in the case you are talking about?

Otherwise there is only one solution: a mailbox-is-readonly policy
has to be introduced.
That will surely drive users insane which see that they in fact
have write access to the file.
Python has got bad cards.

----------

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

From report at bugs.python.org  Thu May  5 16:34:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 May 2011 14:34:45 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1304606085.02.0.656234707635.issue12006@psf.upfronthosting.co.za>


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

This is a reasonable request and easy to implement.  I am not sure how often this functionality is needed, so I am only +0 on this feature.

----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.3

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

From report at bugs.python.org  Thu May  5 16:42:16 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 14:42:16 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304595748.98.0.796340638276.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110505144208.GB70318@sherwood.local>


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

> The problem report in question was submitted by one of the
> Debian maintainers.

Yeah, a documentainer at least.
I've used Debian (Woody i think that was 3.1).
Actually great because Lehmanns, Heidelberg, Germany did not
include the sources but they've sent me the sources (on seven CD's
as far as i remember) for free after i've complained.

Linux is really great.  You don't need internet access at all
because of that fantastic documentation, everywhere.  You look
into /dev and /sys and /proc and it's all so translucent!!  And
the GNU tools and libraries - they are so nicely designed.
The source code is so clean.  It's really an enlightened system.

Then i discovered FreeBSD 4.8 which released me from all that.
\|/
_ .
 |
 -
 |
(I still had hairs at that time.  But that was long ago.)

----------

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

From report at bugs.python.org  Thu May  5 16:46:00 2011
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 05 May 2011 14:46:00 +0000
Subject: [issue6116] frame.f_locals keeps references to things for too long
In-Reply-To: <1243351626.66.0.213520935039.issue6116@psf.upfronthosting.co.za>
Message-ID: <1304606760.56.0.825883382704.issue6116@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Making a copy of f_locals values to return a dictionary that doesn't hold references to the locals of the frame is not that simple (for me, at least):

- shallow copy: we'll return always a new dict, with the values being a copy of locals; this is simpler, but what about other objects that are referenced in in those values? For example, in locals exists a list A which holds a reference to object B; the new dict we return will have copy of A, but this copy will still reference B.

- deep copy: we'll return a new dict with a deep copy of all values; this is safer, but what about memory? In any case, how we could do a deep copy here? calling Python's code copy.deepcopy()?

I want to add a fourth option to JP's initial ones:

- have other attribute, something like f_locals_weak that is a list of tuples [(name, value), ...], being the values a weak reference to the real locals.

What do you think?

Regards,

----------
nosy: +facundobatista

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

From report at bugs.python.org  Thu May  5 17:33:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 May 2011 15:33:39 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1304609619.35.0.454817232278.issue665194@psf.upfronthosting.co.za>


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

Rather than shoehorning datetime class support into existing functions, I think a separate set of functions should be written to convert between RFC 2822 timestamps and datetime instances.  Currently, email.utils has three functions dealing with date-time specification in email messages:

formatdate(timeval=None, localtime=False, usegmt=False),
parsedate(data),
parsedate_tz(data)

To work with datetime instances, we can just provide two functions.  For lack of better names, I'll call them format_datetime and parse_datetime.  Rather than using a localtime flag in the format function, I suggest to always interpret naive datetime instances (those with tzinfo = None) as time given in UTC with no information about the local time zone. Per RFC  2822, this should be formatted with "-0000" in the timezone field.  The format_datetime() may take usegmt flag, but it may be better to handle usegmt=True case by a separate format_datetime_gmt() function.

The parse_datetime() function should use a similar convention and produce aware datetime instances unless TZ field contains "-0000".  In this case a naive datetime containing unchanged time data should be produced.

The problem of guessing the local timezone offset or converting naive datetime instance presumed to be in local time to an aware instance does not belong to the email package.  This functionality should be added to the datetime module.  See issue 9527.

There is a remaining question to which I don't have an immediate answer: How should parse_datetime() handle valid RFC 2882 date-time specifications that cannot be represented as a valid datetime.  For example, a spec with seconds=60 or timezone > 2400.

----------

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

From report at bugs.python.org  Thu May  5 17:39:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 May 2011 15:39:04 +0000
Subject: [issue11965] Simplify context manager in os.popen
In-Reply-To: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>
Message-ID: <1304609944.74.0.816916220771.issue11965@psf.upfronthosting.co.za>


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

Looks like I?ve misunderstood and there is no duplication.  If you feel sure about it, please reject and close this report.

----------

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

From report at bugs.python.org  Thu May  5 17:47:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 15:47:04 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304610424.6.0.254596604566.issue11935@psf.upfronthosting.co.za>


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

Steffen, your sense of humor is great, but oftentimes I have no clue what you are talking about.  Where does ftruncate factor in?

I was asking what mutt does when it modifies a file in the hopes that it had some pithy algorithm for making sure the mailbox atime and utime conform to the semi-standard you are talking about, so we could steal it.

I'd like to see a solution to this issue.  My two problems with your patch are (1) it feels wrong to set the atime earlier than the last actual atime and (2) unconditionally doing the work in flush means it might get set even when there wasn't an intended "new mail" condition.

In other words, I think the fix is ugly :).  However, neither of those concerns are necessarily blockers.  Practicality beats purity in many cases, and this may be one of them.

----------

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

From report at bugs.python.org  Thu May  5 17:50:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 15:50:10 +0000
Subject: [issue6116] frame.f_locals keeps references to things for too long
In-Reply-To: <1243351626.66.0.213520935039.issue6116@psf.upfronthosting.co.za>
Message-ID: <1304610610.37.0.419137419206.issue6116@psf.upfronthosting.co.za>


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

> Making a copy of f_locals values to return a dictionary that doesn't 
> hold references to the locals of the frame is not that simple

I think you misunderstood the bug report. The issue here is not that locals are referenced from the dict, it's that the dict is kept alive (since it is cached) longer that it should.

By the way, reading the discussion again, I think we could simply make dicts weak-referenceable. A dict is already quite big in memory and I don't think adding a pointer to the struct would make a significant difference.

----------
nosy: +gvanrossum, rhettinger

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

From report at bugs.python.org  Thu May  5 17:51:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 May 2011 15:51:10 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304610670.38.0.676898159798.issue11935@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May  5 18:07:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 16:07:08 +0000
Subject: [issue12007] Console commands won't work
In-Reply-To: <1304592366.23.0.247868928288.issue12007@psf.upfronthosting.co.za>
Message-ID: <1304611628.61.0.050463794055.issue12007@psf.upfronthosting.co.za>


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

I believe this is out of scope for Python itself, and is a platform distribution issue.  The platform must do some special magic to make those things work; they don't in a vanilla python build as far as I know.  You might look to your readline configuration for clues.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Thu May  5 18:11:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 16:11:39 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1304611899.67.0.365383917135.issue12009@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +r.david.murray
stage:  -> test needed
type: crash -> behavior

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

From report at bugs.python.org  Thu May  5 18:15:20 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 May 2011 16:15:20 +0000
Subject: [issue6116] frame.f_locals keeps references to things for too long
In-Reply-To: <1243351626.66.0.213520935039.issue6116@psf.upfronthosting.co.za>
Message-ID: <1304612120.63.0.381770265221.issue6116@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I vote for option 1. We already eschew hacks with locals().

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Thu May  5 18:19:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2011 16:19:11 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <E1QI1GZ-0001Sq-CU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 76bd26565cc7 by R David Murray in branch '3.2':
#11873: Improve test regex so random directory names don't cause test to fail
http://hg.python.org/cpython/rev/76bd26565cc7

New changeset 83e069281810 by R David Murray in branch 'default':
Merge: #11873: Improve test regex so random directory names don't cause test to fail
http://hg.python.org/cpython/rev/83e069281810

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

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

From report at bugs.python.org  Thu May  5 18:20:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 16:20:27 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304612427.81.0.0185874304821.issue11873@psf.upfronthosting.co.za>


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

I ran the patched version 2945 times without failure.

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

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

From report at bugs.python.org  Thu May  5 18:23:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 16:23:13 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304612593.15.0.292994631235.issue11873@psf.upfronthosting.co.za>


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

+        self.assertRunOK('-q', '-x', 'ba[^\/]*$', self.pkgdir)

This regex matchs 'ba(...)\'. I think that you wanted to write r'[^\\/]'.

----------

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

From report at bugs.python.org  Thu May  5 18:26:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 16:26:28 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304612788.14.0.104347063637.issue8407@psf.upfronthosting.co.za>


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

Quick review at http://bugs.python.org/review/8407/show

----------

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

From report at bugs.python.org  Thu May  5 18:38:41 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 16:38:41 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304610424.6.0.254596604566.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110505163830.GA1595@sherwood.local>


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

After half an hour of shallow inspection.

mutt really modifies mailbox files in place (mbox_sync_mailbox())
after creating (all the new tail in) a temporary file.  Then
seek()/write()/truncate() etc..  It however has mutt_dotlock(1)
and it does block signals and it is a standalone program and thus
i don't think this behaviour can be used by Python.

In respect to our issue here i must really admit that mutt does:

    prepare new tail
    stat box
    modify box to incorporate tail
    close box
    utime box with stat result times
    reopen box

So actually the result looks as if it never has been modified.
But maybe it is because like this it is in sync with the standart,
since strictly speaking there is no *new* mail in the box.

Unless you vote against it i'll write a patch tomorrow which will
use a state machine which only triggers the utime if some kind of
setitem has occurred.  I can't help you to overcome your malaise
against soiling an atime's pureness.
'Really want a future date??

----------

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

From report at bugs.python.org  Thu May  5 18:44:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 16:44:04 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1304613844.27.0.243381227381.issue665194@psf.upfronthosting.co.za>


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

Do you think we can get 9527 in?  My patch was based on the non-existence of a LocalTimezone facility in the stdlib.

Good point about the special interpretation of -0000.  Given 9527 (and only given 9527) it would indeed make sense to restrict email to aware datetimes plus naive datetimes for -0000 timestamps.

I'll have to keep a flag for the 60th second  outside of the datetime instance (or pretend it doesn't exist :)

----------
dependencies: +Add aware local time support to datetime module

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

From report at bugs.python.org  Thu May  5 18:53:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 16:53:41 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304614421.83.0.710238643477.issue11873@psf.upfronthosting.co.za>


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

You are right that I got the regex wrong (I'm bad at regexes), but in fact it is fine the way it is.  Since there's no r, the regex is actually "ba[^/]$", which is exactly what I meant.

----------

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

From report at bugs.python.org  Thu May  5 19:04:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 17:04:16 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304615056.53.0.92472438221.issue11935@psf.upfronthosting.co.za>


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

"prepare new tail" means all of the text from the first modified line to the end?  (As opposed to "just the new mail"?)

mailbox does locking.  I see no reason in principle it couldn't stat/restore, it would just be setting the times on the new file rather than on a truncated/rewritten old file.  How hard that would be to incorporate into the existing logic I have no idea.  Of course there may be issues about this I haven't thought of.

>From what you said, if mutt is the model for what mailbox should do, it shouldn't set the mtime later than the atime itself, it should only preserve it if it already was.  Which was my point about using mailbox as a delivery agent: if you *are* using it as a delivery agent, then the application using it as a delivery agent would be the one to set the mtime greater than the atime.  mailbox itself would (following the mutt model) just be preserving the existing relationships.

Do you think the mutt model is a good one to follow?

----------

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

From report at bugs.python.org  Thu May  5 19:04:51 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 17:04:51 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1304615091.9.0.235536193734.issue11935@psf.upfronthosting.co.za>


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

Oh, and does mutt's behavior apply to any mbox, or only the one in the system spool?

----------

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

From report at bugs.python.org  Thu May  5 19:36:35 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 May 2011 17:36:35 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
In-Reply-To: <1304613844.27.0.243381227381.issue665194@psf.upfronthosting.co.za>
Message-ID: <BANLkTinYLKrCsXtQ2QLxSRQJeZe5usHDew@mail.gmail.com>


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

On Thu, May 5, 2011 at 12:44 PM, R. David Murray <report at bugs.python.org> wrote:
..
> Do you think we can get 9527 in?

I hope we can.  Pure Python implementation can be improved by deducing
the TZ offset from localtime() and gmtime() calls.  In C we can use
additional struct tm fields when they are available to do even better.
 Would you like to add your voice to support #9527?

..
> I'll have to keep a flag for the 60th second ?outside of the datetime instance (or pretend it doesn't exist :)

If you can find an e-mail message archived somewhere with 60 seconds
in the timestamp, it will be a powerful argument to extend seconds
range that can be stored in datetime objects.   I doubt such messages
exist, though.  Few systems can produce such a timestamp even if they
happen to process an e-mail during a leap second.  In
parse_datetime(), your choice will be between raising an error and
approximating the leap second with the nearest representable time.  I
think clamping 60 seconds to 59 is the best option and this is what
datetime.fromtimestamp does if the system happens to produce a leap
second in the timetuple.

----------

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

From report at bugs.python.org  Thu May  5 20:01:38 2011
From: report at bugs.python.org (Pas)
Date: Thu, 05 May 2011 18:01:38 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1304618498.05.0.424748824753.issue10399@psf.upfronthosting.co.za>


Changes by Pas <pasthelod at gmail.com>:


----------
nosy: +pas

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

From report at bugs.python.org  Thu May  5 20:14:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 18:14:57 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1304619297.1.0.882131918728.issue9527@psf.upfronthosting.co.za>


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

LocalTimezone support would be *really* helpful for the email module.  It would allow us to have unambiguous semantics for datetime objects representing timestamps exacted from or inserted into email messages (see issue 665194 for recent discussion).  The email module is already trying to handle timestamp translation, and I'd be willing to bet it is buggier than the proposal here.

At one point I even started to copy the LocalTimezone class from the docs into the email module.  I implemented a naive extension of the current formatdate function instead, but after Alexander's feedback on #665194 I think the naive implementation is not a good idea.

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

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

From report at bugs.python.org  Thu May  5 20:18:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2011 18:18:09 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1304619489.29.0.373818684013.issue665194@psf.upfronthosting.co.za>


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

Yes, since the package will save the original text anyway, I think just clamping to 59 is best.

Hmm.  Maybe instead I could put in an assert that says "please report this incident to bugs.python.org so we can argue that datetime should get support for leap seconds) :)

----------

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

From report at bugs.python.org  Thu May  5 20:27:20 2011
From: report at bugs.python.org (Pas)
Date: Thu, 05 May 2011 18:27:20 +0000
Subject: [issue1479611] speed up function calls
Message-ID: <1304620040.64.0.116204545926.issue1479611@psf.upfronthosting.co.za>


Changes by Pas <pasthelod at gmail.com>:


----------
nosy: +pas

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

From report at bugs.python.org  Thu May  5 20:45:59 2011
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 05 May 2011 18:45:59 +0000
Subject: [issue6116] frame.f_locals keeps references to things for too long
In-Reply-To: <1243351626.66.0.213520935039.issue6116@psf.upfronthosting.co.za>
Message-ID: <1304621159.79.0.814665093364.issue6116@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Antoine, to see if I understood correctly... if we build the dict, and just return it but don't save it in the frame, this leak would be solved? (yes, it'd be slower because everytime it's asked, it'd need to be built again)

----------

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

From report at bugs.python.org  Thu May  5 20:53:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 May 2011 18:53:49 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304621629.04.0.384700271522.issue8498@psf.upfronthosting.co.za>


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

> Thanks for the tip. I added the unit test and uploaded my final patch
> (which includes all changes).

A couple comments (note that I'm not entitled to accept or commit a patch, so feel free to ignore them if I'm just being a pain):
- "the maximum value is system-dependent (usually 5)"
I would remove this "usually 5" part: since the kernel silently adjusts the value, it shouldn't be of interest to the programmer. Furthermore, this was probably true a decade ago, but nowadays it doesn't hold anymore, Linux for example allows a much higher limit
- port = support.bind_port(srv)
Since you don't care about which port you get bound to, you could discard the port value, or even call srv.bind((HOST, 0)) directly
- I'm not sure that creating a new SocketListenBacklog0Test TestCase just for this check is necessary. Since it's so short, you could just add a new test to e.g. GeneralModuleTests

> Is it ok to remove the files I uploaded previously? 

It's probably a good idea, so there won't be any confusion with "stale" patches and test scripts.

----------
keywords: +needs review

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

From report at bugs.python.org  Thu May  5 21:06:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 19:06:15 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1304555737.32.0.0606655470844.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304622371.3564.11.camel@localhost.localdomain>


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

> As I think about this more... I'm not sure how much performance there
> is to gain here in practice.  It seems like any time I'd want to use
> readinto(), it's because I want to do my own buffering, in which case
> why would I use a BufferedReader?

The difference between buffered I/O and raw I/O isn't only the presence
of a buffer. For example read(N) on a buffered object will loop until N
bytes are satisfied (or EOF is reached), while read(N) on a raw I/O
object will give you whatever the system call returns.

I would add that third-party buffering would be better helped by the
prefetch() method I proposed on python-ideas:
http://mail.python.org/pipermail/python-ideas/2010-September/008179.html

readinto() is really about minimizing copies and allocations when you
already have storage allocated for the result.
(note that TextIOWrapper could have used readinto(), but instead opted
for the slightly useless read1())

----------

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

From report at bugs.python.org  Thu May  5 21:08:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 May 2011 19:08:30 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1304622510.18.0.973675207132.issue8426@psf.upfronthosting.co.za>


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

> You can not pickle individual objects larger than 2**31.

Indeed, but that's not what's happening here, the failure occurs with much smaller objects (also, note the OP's "cPickle is perfectly capable of pickling these objects").
The problem is really with the underlying pipe/unix socket filling up.

----------

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

From report at bugs.python.org  Thu May  5 21:10:27 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 05 May 2011 19:10:27 +0000
Subject: [issue11729] libffi assembler relocation check is not robust,
	fails with clang
In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za>
Message-ID: <1304622627.99.0.52431693796.issue11729@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Ping? Shall I submit a fix for Modules/_ctypes/libffi/configure.ac or better yet will you sync in-tree libffi?

----------

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

From report at bugs.python.org  Thu May  5 21:13:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 19:13:12 +0000
Subject: [issue11729] libffi assembler relocation check is not robust,
	fails with clang
In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za>
Message-ID: <1304622792.38.0.50410182024.issue11729@psf.upfronthosting.co.za>


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

Well, ctypes is kindof unmaintained right now, and the private libffi copy belongs to that module.
(the reason we have a libffi copy is that, IIUC, it's patched)

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

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

From report at bugs.python.org  Thu May  5 21:13:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 19:13:58 +0000
Subject: [issue11729] libffi assembler relocation check is not robust,
	fails with clang
In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za>
Message-ID: <1304622838.42.0.975366088774.issue11729@psf.upfronthosting.co.za>


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


----------
nosy: +doko

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

From report at bugs.python.org  Thu May  5 21:14:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 May 2011 19:14:18 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1304622858.54.0.450003426951.issue11149@psf.upfronthosting.co.za>


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

Brett, can you test this?

----------
assignee:  -> brett.cannon
nosy: +rhettinger

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

From report at bugs.python.org  Thu May  5 21:17:33 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 05 May 2011 19:17:33 +0000
Subject: [issue11729] libffi assembler relocation check is not robust,
	fails with clang
In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za>
Message-ID: <1304623053.49.0.145231686397.issue11729@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Patch for configure.ac then?

----------

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

From report at bugs.python.org  Thu May  5 21:24:46 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Thu, 05 May 2011 19:24:46 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1304623486.73.0.362530799279.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

At least in Denmark, week numbers are used regularly in everyday communication and planning, and the numbering follows the ISO rules. Also, the week starts on Monday.

----------

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

From report at bugs.python.org  Thu May  5 22:00:11 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Thu, 05 May 2011 20:00:11 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1304625611.67.0.0399143769929.issue11163@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Here is the patch to fix the documentation. Asked some core developers off the bug tracker how to handle this bug in relation to the bigger issue regarding "STOP" leading to an infinite loop.

----------
keywords: +patch
nosy: +louiscipher
Added file: http://bugs.python.org/file21898/issue11163.py33.patch

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

From report at bugs.python.org  Thu May  5 22:28:49 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 20:28:49 +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: <20110505202838.GA17620@sherwood.local>


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

In fact i like my idea of using iterations.
I have some time tomorrow, so if nobody complains until then,
i write diffs for the tests of 3.x and 2.7 with these updates:

- Two different target sizes:
    1. 0xFFFFFFFF + x (7)
    2. 0x7FFFFFFF + x (7)
- On 32 bit systems, use iterations on a potentially safe buffer
  size.  I think 0x40000000 a.k.a 1024*1024*1024 is affordable,
  but 512 MB are probably more safe?  I'll make that a variable.
- The string will be 'DeadAffe' (8).
- The last 4 bytes of the string will always be read on their own
  (just in case the large buffer sizes irritated something down
  the path).

----------

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

From report at bugs.python.org  Thu May  5 22:37:09 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 20:37:09 +0000
Subject: [issue7359] mailbox cannot modify mailboxes in system mail spool
In-Reply-To: <1258647326.68.0.261951425057.issue7359@psf.upfronthosting.co.za>
Message-ID: <1304627829.82.0.379945974113.issue7359@psf.upfronthosting.co.za>


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

Issue #11935 becomes gigantic and may even swamp this one over!

----------
nosy: +sdaoden

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

From report at bugs.python.org  Thu May  5 22:37:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 May 2011 20:37:11 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1304627831.93.0.475762062243.issue11163@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think this is the wrong patch for reasons given below.
The example should be replaced instead.

Readline is documented as returning '' at EOF for text files.
Iter(func,sentinel) is documented as calling func until sentinel is returned. If that never happens, it never stops. That makes it dangerous unless one KNOWS for sure that the sentinel WILL be returned or is willing to continue indefinitely. I think a sentence should be added to the doc to warn about this.

So I consider the premise of the example, "One useful application of the second form of iter() is to read lines of a file until a certain line is reached.", to be somewhat dubious. The example could be considered instead to be an example of when NOT to use the second form. This application should better be written to avoid a possible infinite loop as

with open(name) as fp:
  for line in fp:
    if line == sentinel:
      break
    process(line)

I think a better example would be (3.2 version, use raw_input for 2.7):

def my_input():
    return input("Enter data or return to stop: ")
for data in iter(my_input, ''):
    process(data)

Your alternative also works, but the above is something one might actually do. Even that is hardly much better than:

while True:
  data = input("Enter data or return to stop}
  if not data: break
  process data

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Thu May  5 22:37:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 May 2011 20:37:24 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1304627844.09.0.871151784016.issue11163@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Thu May  5 22:45:30 2011
From: report at bugs.python.org (David Coles)
Date: Thu, 05 May 2011 20:45:30 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>


New submission from David Coles <coles.david at gmail.com>:

On Android platforms bionic defines wchar_t as char. This causes compiling of unicodeobject.c to fail with "#error "unsupported wchar_t and PyUNICODE sizes, see issue #8670".

The unusual thing is that the configure script does detect if wchar_t is usable (HAVE_USABLE_WCHAR_T) but the wide code support block in unicodeobject.c does not check this (only an #ifdef HAVE_WCHAR_T).

Possibly the quick solution is to change this #ifdef to '#if defined(HAVE_WCHAR_T) && defined(HAVE_USABLE_WCHAR_T)'. The header unicodeobject.h does check for HAVE_USABLE_WCHAR_T but will only define HAVE_WCHAR_T if it is not already defined.

----------
components: Build
messages: 135242
nosy: dcoles
priority: normal
severity: normal
status: open
title: Compile fails when sizeof(wchar_t) == 1
type: compile error

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

From report at bugs.python.org  Thu May  5 22:49:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 20:49:40 +0000
Subject: [issue12011] The signal module should raise OSError for OS-related
	exceptions, not RuntimeError
In-Reply-To: <1304628580.22.0.561171702394.issue12011@psf.upfronthosting.co.za>
Message-ID: <1304628580.22.0.561171702394.issue12011@psf.upfronthosting.co.za>


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

Treating RuntimeError as if it could take an errno is no good:

>>> try: signal.siginterrupt(32, 12345)
... except RuntimeError as e: print(e.errno)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: (22, 'Invalid argument')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
AttributeError: 'RuntimeError' object has no attribute 'errno'


Changing it breaks compatibility a bit but I think it's worth it.

----------
components: Library (Lib)
messages: 135243
nosy: haypo, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: The signal module should raise OSError for OS-related exceptions, not RuntimeError
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu May  5 22:56:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 20:56:06 +0000
Subject: [issue12011] The signal module should raise OSError for OS-related
	exceptions, not RuntimeError
In-Reply-To: <1304628580.22.0.561171702394.issue12011@psf.upfronthosting.co.za>
Message-ID: <1304628966.44.0.879061821939.issue12011@psf.upfronthosting.co.za>


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

I asked if I should use RuntimeError or OSError for the new signal functions (#8407) on python-dev. Georg Brandl answered:

"If it has an errno, it should be a subclass of EnvironmentError."

----------

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

From report at bugs.python.org  Thu May  5 22:56:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 20:56:33 +0000
Subject: [issue12011] The signal module should raise OSError for OS-related
	exceptions, not RuntimeError
In-Reply-To: <1304628580.22.0.561171702394.issue12011@psf.upfronthosting.co.za>
Message-ID: <1304628993.74.0.324967565685.issue12011@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May  5 22:58:06 2011
From: report at bugs.python.org (John O'Connor)
Date: Thu, 05 May 2011 20:58:06 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304629086.4.0.608262018582.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

Attached patch draft for buffered_readinto(). patchcheck removed some whitespace as well.

Daniel, I agree. BufferedReader.readinto seemingly defeats the purpose of using a BufferedReader to begin with. Though, for the difference Antoine pointed out it makes sense (more of an accumulator).

Interesting thread about prefetch(). +1

----------
keywords: +patch
Added file: http://bugs.python.org/file21899/buffered_readinto.patch

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

From report at bugs.python.org  Thu May  5 22:58:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 May 2011 20:58:58 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1304629138.72.0.528727339431.issue11163@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger

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

From report at bugs.python.org  Thu May  5 23:00:41 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 May 2011 21:00:41 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1304629241.17.0.756892304615.issue11163@psf.upfronthosting.co.za>


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

I'll replace this with a better example using binary chunked reads that terminate with an empty string.

----------
priority: normal -> low

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

From report at bugs.python.org  Thu May  5 23:02:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 21:02:57 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1304629377.01.0.793036953907.issue12010@psf.upfronthosting.co.za>


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

Do you want to propose a patch? I'm not sure any of us can test on an Android setup.

----------
nosy: +pitrou
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May  5 23:07:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 21:07:37 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1304629657.65.0.625307656829.issue12010@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/issue12010>
_______________________________________

From report at bugs.python.org  Thu May  5 23:21:14 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 05 May 2011 21:21:14 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304615056.53.0.92472438221.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110505212104.GA33247@sherwood.local>


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

On Thu,  5 May 2011 19:04:16 +0200, R. David Murray wrote:
> "prepare new tail" means all of the text from the first modified
> line to the end?  (As opposed to "just the new mail"?) mailbox
> does locking.  I see no reason in principle it couldn't
> stat/restore, it would just be setting the times on the new file
> rather than on a truncated/rewritten old file.  How hard that
> would be to incorporate into the existing logic I have no idea.
> Of course there may be issues about this I haven't thought of.

Me too and even more.
Clearly mailbox.py cannot do any dotlocking due to missing
permissions, so this is silently ignored to be able to proceed at
all.  Therefore only fcntl/flock locking is used for
a /var/{spool/}mail box by mailbox.py.  This is fine as long as
all programs agree in locking such a file in the usual way, that
is, use both, dotlocking *and* flock/lock, and restart from the
beginning if one of them fails due to another program holding that
very lock.  mutt does that but i won't do any bet here.

And then the signal handling, and Python even supports threading,
and it is embeddable and there may be third-party modules also
involved.  This is the Death Valley of programming.

    $PYP mb.flush()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py", line 659, in flush
        new_file = _create_temporary(self._path)
      File "/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py", line 2061, in _create_temporary
        os.getpid()))
      File "/Users/steffen/usr/opt/py3k/lib/python3.3/mailbox.py", line 2051, in _create_carefully
        fd = os.open(path, os.O_CREAT | os.O_EXCL | os.O_RDWR, 0o666)
    OSError: [Errno 13] Permission denied: '/var/mail/steffen.1304628960.sherwood.local.37135'

So this seems to be the safest and most useful approach in this
context, because i do not want to imagine what happens if
something weird occurs in the middle of writing "the tail"
otherwise.  So i stop thinking about issue #7359.

> Do you think the mutt model is a good one to follow?

You mean resetting atime/mtime back to before the rename?
I don't like that and i don't understand it because the file has
been modified, so i think i would do (now,now) in that case
instead (because of the MMDF/MBOX newer==new mail case).
And in case a new mail has been inserted (now-2.42,now).

----------

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

From report at bugs.python.org  Thu May  5 23:28:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2011 21:28:34 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304630914.99.0.604977677123.issue9971@psf.upfronthosting.co.za>


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

Thank you for the patch. A couple of comments:

- the whole slow path (which loops calling _bufferedreader_raw_read()) should be surrounded by calls to ENTER_BUFFERED() and LEAVE_BUFFERED()

- other things:

+    if (!PyArg_ParseTuple(args, "O:readinto", &buffer))
+        return NULL;
+
+    if (PyObject_GetBuffer(buffer, &buf, PyBUF_CONTIG) == -1)
+        return NULL;

You should use the "w*" typecode instead (see the readinto implementation in Modules/_io/fileio.c for an example).

+            if (n == -2) {
+                Py_INCREF(Py_None);
+                res = Py_None;
+            }

If `written` is > 0, this should return the number of bytes instead (mimicking _bufferedreader_read_generic). Adding a test for that would be nice too (in Lib/test/test_io.py).

----------

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

From report at bugs.python.org  Thu May  5 23:29:27 2011
From: report at bugs.python.org (David Coles)
Date: Thu, 05 May 2011 21:29:27 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1304630967.38.0.378588761744.issue12010@psf.upfronthosting.co.za>


David Coles <coles.david at gmail.com> added the comment:

Sure. There are a few other build issues (mainly missing types/structs in Bionic) that are preventing a complete build. I'll put together a patch once I have a working build and can verify that HAVE_USABLE_WCHAR_T is set correctly set on a normal Linux build.

----------

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

From report at bugs.python.org  Fri May  6 00:41:46 2011
From: report at bugs.python.org (John O'Connor)
Date: Thu, 05 May 2011 22:41:46 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304635306.95.0.0585890712501.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

Thanks for the feedback. I made the changes, PTAL.

----------
Added file: http://bugs.python.org/file21900/buffered_readinto2.patch

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

From report at bugs.python.org  Fri May  6 00:53:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 22:53:03 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304635983.69.0.65763261206.issue8407@psf.upfronthosting.co.za>


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

> http://bugs.python.org/review/8407/show

Updated patch (version 2).

Note: sigpending() doesn't return an error code but -1 on error.

----------
Added file: http://bugs.python.org/file21901/pending_signals-2.patch

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

From report at bugs.python.org  Fri May  6 01:35:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 May 2011 23:35:41 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>


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

It looks like OpenSSL can be compiled without SSLv2 (#ifdef OPENSSL_NO_SSL2). See this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612780

When compiling Python, I get the following error:
/home/haypo/prog/HG/cpython/Modules/_ssl.c: In function 'context_new':
/home/haypo/prog/HG/cpython/Modules/_ssl.c:1451:9: warning: implicit declaration of function 'SSLv2_method'
/home/haypo/prog/HG/cpython/Modules/_ssl.c:1451:9: warning: passing argument 1 of 'SSL_CTX_new' makes pointer from integer without a cast
/usr/include/openssl/ssl.h:1469:10: note: expected 'const struct SSL_METHOD *' but argument is of type 'int'
*** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-x86_64-3.3-pydebug/_ssl.cpython-33dm.so: undefined symbol: SSLv2_method

See also issue #9415.

---

Attached patch makes ssl.PROTOCOL_SSLv2 optional.

I don't know what to do with @skip_if_broken_ubuntu_ssl in test_ssl.py.

----------
components: Extension Modules
files: nosslv2.patch
keywords: patch
messages: 135253
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: _ssl module doesn't compile with OpenSSL 1.0.0d: SSLv2_method is missing
versions: Python 3.3
Added file: http://bugs.python.org/file21902/nosslv2.patch

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

From report at bugs.python.org  Fri May  6 02:08:08 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2011 00:08:08 +0000
Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors
In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za>
Message-ID: <1304640488.71.0.106063858169.issue12004@psf.upfronthosting.co.za>


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

Could you incorporate the test into Lib/test/test_zipfile?

Thanks!

----------
components: +Library (Lib)
nosy: +eric.smith

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

From report at bugs.python.org  Fri May  6 02:54:07 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 06 May 2011 00:54:07 +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: <1304643247.49.0.687409902496.issue11277@psf.upfronthosting.co.za>


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

haypo> Can we just remove the test?

I think so. The test was originally intended to catch the case where crc32() or
adler32() would get a buffer of >=4GB, and then silently truncate the size and
produce an incorrect result (issue10276). However, 2.7's zlib doesn't define
PY_SSIZE_T_CLEAN, so passing in a buffer of >=2GB raises an exception. So the
condition that it was testing for can't happen in 2.7.


sdaoden> Can we remove it?  I would keep it, Apple is preparing the next
sdaoden> major release (uname -a yet states 10.7.0 even though it's
sdaoden> 10.6.7), and maybe then mmap() will fail for 0xDEADBEEF.
sdaoden> Who will be the one which detects that otherwise??

I initially thought the same thing, but it turns out that the OS X sparsefile
crash is also covered by LargeMmapTests.test_large_offset() in test_mmap.
That test had also been failing sporadically before the F_FULLSYNC patch was
committed (see issue11779). So keeping this test around would be redundant.


sdaoden> Unfortunately we cannot test 0x80000000+ no more because
sdaoden> Python prevents that such a buffer can be used - that's a shame.
sdaoden> Maybe we could test 0x7FFFFFFF*2 aka 0xfffffffe in two iterations.

That wouldn't accomplish the same thing. The point of the test is to pick up
truncation issues that occur when you pass in a big buffer. These issues
won't show up if you split the data up into smaller pieces. And in any case,
they can't happen at all in 2.7, because the functions don't accept big
buffers in the first place ;)

----------

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

From report at bugs.python.org  Fri May  6 03:04:53 2011
From: report at bugs.python.org (Ben Morgan)
Date: Fri, 06 May 2011 01:04:53 +0000
Subject: [issue12004] PyZipFile.writepy gives internal error on syntax errors
In-Reply-To: <1304562440.9.0.83817194423.issue12004@psf.upfronthosting.co.za>
Message-ID: <1304643893.58.0.212718092075.issue12004@psf.upfronthosting.co.za>


Ben Morgan <benpmorgan at gmail.com> added the comment:

I've attached a patch to test_zipfile.py. I noticed that it writes out the error to stdout not stderr; I don't know if this is the desired behaviour.

----------
Added file: http://bugs.python.org/file21903/test-zipfile.patch

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

From report at bugs.python.org  Fri May  6 03:16:25 2011
From: report at bugs.python.org (Alex Lai)
Date: Fri, 06 May 2011 01:16:25 +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: <1304644585.52.0.347221630935.issue12013@psf.upfronthosting.co.za>


New submission from Alex Lai <alex_lai at scotiacapital.com>:

Hi guys,
  I was knocked down by a error related to a socket library _socket.so when I was trying to compile distribute-0.6.14:

# python3 setup.py install
Before install bootstrap.
Scanning installed packages
No setuptools distribution found
running install
Traceback (most recent call last):
  File "setup.py", line 211, in <module>
    scripts = scripts,
  File "/usr/local/lib/python3.1/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.1/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "build/src/setuptools/command/install.py", line 73, in run
    self.do_egg_install()
  File "build/src/setuptools/command/install.py", line 82, in do_egg_install
    easy_install = self.distribution.get_command_class('easy_install')
  File "build/src/setuptools/dist.py", line 361, in get_command_class
    self.cmdclass[command] = cmdclass = ep.load()
  File "build/src/pkg_resources.py", line 1954, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "build/src/setuptools/command/easy_install.py", line 24, in <module>
    from setuptools.package_index import PackageIndex
  File "build/src/setuptools/package_index.py", line 2, in <module>
    import sys, os.path, re, urllib.parse, urllib.request, urllib.error, urllib.parse, shutil, random, socket, io
  File "/usr/local/lib/python3.1/urllib/request.py", line 88, in <module>
    import http.client
  File "/usr/local/lib/python3.1/http/client.py", line 69, in <module>
    import email.parser
  File "/usr/local/lib/python3.1/email/parser.py", line 12, in <module>
    from email.feedparser import FeedParser
  File "/usr/local/lib/python3.1/email/feedparser.py", line 27, in <module>
    from email import message
  File "/usr/local/lib/python3.1/email/message.py", line 17, in <module>
    from email import utils
  File "/usr/local/lib/python3.1/email/utils.py", line 28, in <module>
    import socket
  File "/usr/local/lib/python3.1/socket.py", line 45, in <module>
    import _socket
ImportError: ld.so.1: python3: fatal: relocation error: file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found


# ls -l /usr/local/lib/python3.1/lib-dynload/_socket.so
-rwxr-xr-x   1 bin      bin       113860 Mar 23  2010 /usr/local/lib/python3.1/lib-dynload/_socket.so
# ldd /usr/local/lib/python3.1/lib-dynload/_socket.so
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        libc.so.1 =>     /lib/libc.so.1
        libm.so.2 =>     /lib/libm.so.2
        /platform/SUNW,Ultra-5_10/lib/libc_psr.so.1


Could anyone advise what does this error message mean?

Thanks in advance,

Alex

----------
messages: 135257
nosy: alex_lai
priority: normal
severity: normal
status: open
title: file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri May  6 03:45:59 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 06 May 2011 01:45:59 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>


New submission from Ben Wolfson <wolfson at gmail.com>:

As near as I can make out from <http://docs.python.org/library/string.html#formatstrings>, the following should return the string "hi":

"{0[!]}".format({"!":"hi"})

We have a "{", followed by a field name, followed by a "}", the field name consisting of an arg_name, which is 0, a "[", an element index, and a "]". The element index, which the docs say may be any source character except "]", is here "!". And, according to the docs, "An expression of the form '.name' selects the named attribute using getattr(), while an expression of the form '[index]' does an index lookup using __getitem__()".

However, it doesn't work:
>>> "{0[!]}".format({"!":"hi"})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Missing ']' in format string

The same thing happens with other strings that are significant in other places in the string-formatting DSL:

>>> "{0[:]}".format({":":"hi"})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Missing ']' in format string

If there are more characters the error message changes:

>>> class spam:
...     def __getitem__(self, k): return "hi"
... 
>>> "{0[this works as expected]}".format(spam())
'hi'
>>> "{0[I love spam! it is very tasty.]}".format(spam())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: expected ':' after format specifier
>>> "{0[.]}".format(spam()) # periods are ok
'hi'
>>> "{0[although curly braces, }, are not square brackets, they also don't work here]}".format(spam())

Right square brackets work fine, though:

>>> "{0[[]}".format(spam())
'hi'

The failure of the expected result with curly braces presumably indicates at least part of the cause of the other failures: namely, that they stem from supporting providing flags to one replacement field using another, as in "{1:<{0}}". Which is quite useful. But it obviously isn't universally supported in the case of index fields anyway:

>>> "{0[recursive {1[spam]}]}".format(spam(), spam())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Only '.' or '[' may follow ']' in format field specifier

(Note that this is a very strange error message itself, asis the following, but since one isn't, according to the grammar, allowed to include a "]" where I've got one *anyway*, perhaps that's to be expected:

>>> "{0[recursive {1[spam].lower} ]}".format(spam(), spam())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'str' object has no attribute 'lower} ]'

)

But, even if that would explain why one can't use a "{" in the index field, it wouldn't explain why one can't use a "!" or ":", since if those aren't already part of a replacement field, as indicated by some initial "{", they couldn't have the significance that they do when they *are* part of that field.

----------
components: Interpreter Core
messages: 135258
nosy: Ben.Wolfson
priority: normal
severity: normal
status: open
title: str.format parses replacement field incorrectly
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri May  6 04:43:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 02:43:59 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304649839.94.0.358668470148.issue11999@psf.upfronthosting.co.za>


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

Well, it turns out that this sporadic failure is not a test bug, but a real bug in the mailbox module that the test is revealing.

This issue is the same one that motivated the changes in issue 6896.  Those changes, however, merely reduced the problem, but didn't solve it.

The fundamental problem is that mailbox is relying on comparing the system clock with the mtime.  But the mtime, it turns out, is not guaranteed to follow the system clock.  You can see this most easily if you think about, say, an NSF file system.  The mtime is set by the server's clock, and if the server's clock is different, the mtime won't match the local clock.  It appears to be also true for some reason on a vserver virthost: as reported in issue 6896, the mtime is sometimes set to a value a full second before the time.time() time.

Ironically this was discussed in the original bug report that introduced the mtime checking code (issue 1607951), and I found that bug on the first page of hits while searching for mtime/system clock synchronization problems.  The solution that Andrew proposed in that issue is slightly different from the one he actually implemented, but his proposed solution was also flawed.

The actual solution involves dealing correctly with two factors: the mtime "clock" is not synchronized with the system clock, and the mtime only has a resolution of one second.  The first means that when looking for changes to the mtime we must compare it to the previous value of the mtime.  The second means that if _refresh was last called less than a second ago by our clock (the only one we can query), we had best recheck because the directory may have been updated without the mtime changing.

I also added an additional delta in case the file system clock is skewing relative to the system clock.  I made this a class attribute so that it is adjustable; perhaps it should be made public and documented.

Attached is a patch implementing the fix.  It undoes the 6896 patch, since it is no longer needed.  At this writing my buildbot has run test_mailbox 50 times without failing, where before it would fail every third run or so.

Sadly, I had to reintroduce a 1.1 second fixed sleep into the test.  No way around it.  But it is a deterministic sleep, not a "hope this is long enough" sleep.

----------
Added file: http://bugs.python.org/file21904/mailbox_mtime.patch

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

From report at bugs.python.org  Fri May  6 04:46:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 02:46:17 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304649977.05.0.0771726983408.issue11999@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21904/mailbox_mtime.patch

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

From report at bugs.python.org  Fri May  6 04:46:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 02:46:35 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304649995.21.0.37520985701.issue11999@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file21905/mailbox_mtime.patch

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

From report at bugs.python.org  Fri May  6 04:52:14 2011
From: report at bugs.python.org (John O'Connor)
Date: Fri, 06 May 2011 02:52:14 +0000
Subject: [issue1677872] Efficient reverse line iterator
Message-ID: <1304650334.54.0.539296671873.issue1677872@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

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

From report at bugs.python.org  Fri May  6 07:07:00 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 06 May 2011 05:07:00 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304658420.43.0.728051882002.issue12014@psf.upfronthosting.co.za>


Changes by Ben Wolfson <wolfson at gmail.com>:


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

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

From report at bugs.python.org  Fri May  6 07:49:37 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 May 2011 05:49:37 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1304660977.37.0.214416551305.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Any news on this? Can you check that your patches apply for latest trunk and commit them?

----------

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

From report at bugs.python.org  Fri May  6 07:51:47 2011
From: report at bugs.python.org (Steve Ward)
Date: Fri, 06 May 2011 05:51:47 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>


New submission from Steve Ward <planet36 at gmail.com>:

In this revision <http://hg.python.org/cpython/rev/b6da97930f63>, the possible characters that comprise a temporary file decreased.  It was noted in this thread <http://mail.python.org/pipermail/python-dev/2010-November/105452.html>.  The old character set had more than 24 times as many possibilities! [1]

According to POSIX, the possible characters from which temporary file names should be constructed is [A-Za-z0-9._-].  [2]

The character set should be restored to [A-Za-z0-9_] at the least.  A patch is attached.

The practices of other platforms, libraries, and languages are listed below.  [3-12]



[1]
Old character set: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_
(26+26+10+1) ^ 6
62523502209

Current character set: abcdefghijklmnopqrstuvwxyz0123456789_
(26+10+1) ^ 6
2565726409

62523502209 / 2565726409
24.36873315474378000994



[2] POSIX <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_276>

3.276 Portable Filename Character Set

The set of characters from which portable filenames are constructed.

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -



[3] int mkstemp(char *template); <http://pubs.opengroup.org/onlinepubs/9699919799/functions/mkstemp.html>
The string in template should look like a filename with six trailing 'X' s; mkstemp() replaces each 'X' with a character from the portable filename character set.



[4] glibc <http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/posix/tempname.c;hb=HEAD>
/* These are the characters used in temporary filenames.  */
static const char letters[] =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";



[5] gnulib <http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/tempname.c;hb=HEAD>
/* These are the characters used in temporary file names.  */
static const char letters[] =
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";



[6] freebsd libc <http://svnweb.freebsd.org/base/head/lib/libc/stdio/mktemp.c?view=markup>
static const unsigned char padchar[] =
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";



[7] openbsd libc <http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdio/mktemp.c?rev=HEAD;content-type=text%2Fplain>
#define TEMPCHARS	"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"



[8] netbsd libc <http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/stdio/gettemp.c?rev=HEAD&content-type=text/plain>
(uses pid)



[9] perl <http://perl5.git.perl.org/perl.git/blob/HEAD:/cpan/File-Temp/Temp.pm>
my @CHARS = (qw/ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
                 a b c d e f g h i j k l m n o p q r s t u v w x y z
                 0 1 2 3 4 5 6 7 8 9 _
               /);



[10] php <http://svn.php.net/viewvc/php/php-src/trunk/main/php_open_temporary_file.c?view=markup>
(if Windows, call GetTempFileName; else if havel mkstemp, call it; else call mktemp)



[11] ruby <http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/lib/tmpdir.rb?view=markup>
(uses current date, pid, and a random number between 0 and 4294967296 represented in base 36 (lowercase))



[12] Windows <http://msdn.microsoft.com/en-us/library/aa364991.aspx>
<path>\<pre><uuuu>.TMP

Component	Meaning
<path>	Path specified by the lpPathName parameter
<pre>	First three letters of the lpPrefixString string
<uuuu>	Hexadecimal value of uUnique

Only the lower 16 bits of the uUnique parameter are used. This limits GetTempFileName to a maximum of 65,535 unique file names if the lpPathName and lpPrefixString parameters remain the same.

----------
components: Library (Lib)
files: tempfile.py.diff
keywords: patch
messages: 135261
nosy: planet36
priority: normal
severity: normal
status: open
title: possible characters in temporary file name is too few
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file21906/tempfile.py.diff

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

From report at bugs.python.org  Fri May  6 08:28:31 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 May 2011 06:28:31 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1304663311.37.0.309903332154.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry,

I've incorporated your suggestions except the new formulation for verbosity to doctest.testmod, since it's not really clear which one is more accurate. I think it's intelligible as it is now (especially given that test.support is for use of Python contributors, and not random users). If you have strong preferences about it, feel free to commit another formulation.

Ezio,

I answered your comments in the code review tool.
Regarding the use of assertEqual for the floating point results, I just didn't want to rely on the exact representation of these values. I'm not 100% sure Python ensures this is true on all platforms it supports. Recall that I was just replacing the fcmp code which did basically the same, also not comparing exactly.

----

I will commit a fixed patch to default. I see no reason to backport this since test.support is just a tool for core-devs and contributors and is mainly used for future developments.

----------

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

From report at bugs.python.org  Fri May  6 08:30:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2011 06:30:36 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <E1QIEYd-0006Cg-8x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2fd435ac3551 by Eli Bendersky in branch 'default':
Issue #11015: bring test.support docs up to date
http://hg.python.org/cpython/rev/2fd435ac3551

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

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

From report at bugs.python.org  Fri May  6 08:31:22 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 06 May 2011 06:31:22 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304663482.77.0.628123599626.issue12015@psf.upfronthosting.co.za>


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

- How is it an issue? is the number of combinations really important to you?
- Isn't there a greater risk of collisions on a case-insensitive filesystem?

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

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

From report at bugs.python.org  Fri May  6 09:18:00 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 May 2011 07:18:00 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304666280.53.0.418020125717.issue12014@psf.upfronthosting.co.za>


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


----------
nosy: +eric.smith, mark.dickinson

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

From report at bugs.python.org  Fri May  6 10:00:27 2011
From: report at bugs.python.org (Steve Ward)
Date: Fri, 06 May 2011 08:00:27 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304668827.8.0.396351882662.issue12015@psf.upfronthosting.co.za>


Steve Ward <planet36 at gmail.com> added the comment:

It is an issue because...

1) Python falls out of line with most other popular systems and languages.

2) There was never a good reason to decrease the entropy in the first place.  If there was, the reason of case-sensitive files systems was not given.

3) If case-sensitivity was an issue, why wasn't it raised before?  For more than 8 years (2002-08-09 till 2010-11-09) the issue never warranted a change.

The initial commit is here.
http://svn.python.org/view?view=revision&revision=28113

----------

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

From report at bugs.python.org  Fri May  6 10:13:03 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 06 May 2011 08:13:03 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304669583.23.0.369474538706.issue12015@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


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

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

From report at bugs.python.org  Fri May  6 10:39:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 May 2011 08:39:44 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304671184.84.0.0882482484794.issue8407@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file21901/pending_signals-2.patch

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

From report at bugs.python.org  Fri May  6 10:47:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 May 2011 08:47:05 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304671625.07.0.400528610424.issue8407@psf.upfronthosting.co.za>


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

Oops.
Victor, my mouse got stuck and I mistakenly removed your pending_signals-2 patch. I'm really sorry about this, could you re-post it?

To try to make up for this, a small comment:
In signal_sigwait, at the end of the function,  you do this:

    /* call the signal handler (if any) */
    if (PyErr_CheckSignals())
        return NULL;

I'm not sure I get this: sigwait is used to handle signals synchronously, and in the POSIX semantic, it's incompatible with signal handlers:

"""
sigwait suspends the calling thread until one of the signals in set is delivered to the calling thread. It then stores the number of the signal received in the location pointed to by sig and returns. The signals in set must be blocked and not ignored on entrance to sigwait. If the delivered signal has a signal handler function attached, that function is *not* called.
"""

and
"""
The effect of sigwait() on the signal actions for the signals in set is unspecified.
"""

So, if anything, you shouldn't check for a pending signal.

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

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

From report at bugs.python.org  Fri May  6 10:47:19 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2011 08:47:19 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304671639.03.0.113456644523.issue12014@psf.upfronthosting.co.za>


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

I haven't had time to completely review this, I will do so later today.

But let me just say that the string is first parsed for replacement strings inside curly braces. There's no issue with that, here.

Next, the string is parsed for conversion and format_spec, looking for "!" and ":" respectively. In your first example that gives:

field_name: '0['
conversion : ']'

It then tries to parse the field_name and gives you the first error.

----------

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

From report at bugs.python.org  Fri May  6 11:16:17 2011
From: report at bugs.python.org (zy)
Date: Fri, 06 May 2011 09:16: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: <1304673377.35.0.784853339325.issue12016@psf.upfronthosting.co.za>


New submission from zy <cdqzzy at gmail.com>:

let s='\xff\n' 
The expected result of s.decode('gb2312', 'ignore') is u"\n", while in 2.6.6 it is u"".
  s can be replaced with chr(m) + chr(n) , where m is in range of 128~255, and n in 0~127.
  In the above cases, try decoding from chr(n) will never interfere with later parts in the string if there is any, since chr(n) do not start a multibyte sequence.

----------
components: Unicode
messages: 135268
nosy: cdqzzy
priority: normal
severity: normal
status: open
title: Wrong behavior for '\xff\n'.decode('gb2312', 'ignore')
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri May  6 11:26:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 09:26:34 +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: <1304673994.11.0.458377627291.issue12016@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> test needed
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Fri May  6 11:32:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2011 09:32:04 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <E1QIHOE-0003NA-Rv@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 26da299ca88e by Ronald Oussoren in branch '3.1':
Fix for issue 10684: Folders get deleted when trying to change case with shutil.move (case insensitive file systems only)
http://hg.python.org/cpython/rev/26da299ca88e

New changeset 051190230254 by Ronald Oussoren in branch '2.7':
Backport fix for issue #10684 from 3.x
http://hg.python.org/cpython/rev/051190230254

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

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

From report at bugs.python.org  Fri May  6 11:33:27 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 09:33:27 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304674407.8.0.890742162199.issue10684@psf.upfronthosting.co.za>


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

I've committed the fix in 2.7, 3.1, 3.2 and 3.3

----------
assignee:  -> ronaldoussoren
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri May  6 11:41:21 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 09:41:21 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1304674881.7.0.814606006014.issue9670@psf.upfronthosting.co.za>


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

For pydebug builds the default stacksize should be increased, and prefer to do this by unconditionally changing the stacksize.

W.r.t. the non-osx buildbot failures: it would be better if we could come up with a solution that doesn't disable the test for those platform but I won't do that work. I therefore propose to only enable the test on OSX.

----------

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

From report at bugs.python.org  Fri May  6 12:04:49 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 10:04:49 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304649839.94.0.358668470148.issue11999@psf.upfronthosting.co.za>
Message-ID: <20110506100437.GA50163@sherwood.local>


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

On Fri,  6 May 2011 04:44:00 +0200, R. David Murray wrote:
> [.] the mtime only has a resolution of one second.

You always say that!  But i'm pretty sure from somewhen long ago
that there are filesystems which have a two second time resolution.
And unless i'm mistaken that filesystem is still used widely.

> Attached is a patch implementing the fix.
> It undoes the 6896 patch

I've not yet tried your code but from looking at the patch it
seems to target towards a real approach.

> I also added an additional delta in case the file system clock
> is skewing relative to the system clock.  I made this a class
> attribute so that it is adjustable; perhaps it should be made
> public and documented.

On the other hand, if it shows up after almost five years that the
one second resolution solution doesn't work, and that simply
adjusting to a two second resolution is not smart enough to get
this fixed, then i would not go for something half-automatic which
a user needs to adjust manually, because how could a user do that?

Thus, in my view, if you are *really* looking forward to make
mailbox.py a *good* and *beautiful* thing then the timedelta in
between the filesystem and the host's time() must of course be
tracked-, and the fuzziness should be adjusted automatically.
E.g. similar http://linuxcommand.org/man_pages/adjtimex8.html.

----------

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

From report at bugs.python.org  Fri May  6 12:10:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 10:10:39 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304676639.72.0.586098065332.issue12012@psf.upfronthosting.co.za>


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

Does this happen with a released build of OpenSSL? The Debian bug talks about experimental.

+try:
+    from _ssl import PROTOCOL_SSLv2
+    OPENSSL_NO_SSL2 = False
+except ImportError:
+    OPENSSL_NO_SSL2 = True

Please avoid "negative" constants. Calling it HAS_SSLv2 would be fine.

Also, there should be some doc update mentioning that PROTOCOL_SSLv2 is not always present.

----------

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

From report at bugs.python.org  Fri May  6 12:11:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 10:11:48 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304676708.44.0.478054157116.issue12012@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri May  6 12:27:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 10:27:07 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304649839.94.0.358668470148.issue11999@psf.upfronthosting.co.za>
Message-ID: <20110506102658.GB50163@sherwood.local>


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

> I also added an additional delta in case the file system clock
> is skewing relative to the system clock. 

In fact this idea could even be made public e.g. like this

    class ClockDrifter:
        def add_snapshot(self, exttime, loctime=None):
            if loctime is None:
                loctime = time.time()
            ...
        def drift_tendency(self):
            ...
        def drift_distance(self):
            ...

I could think of usages thereof.

----------

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

From report at bugs.python.org  Fri May  6 12:48:29 2011
From: report at bugs.python.org (Nicolas Bareil)
Date: Fri, 06 May 2011 10:48:29 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304678909.24.0.221095868054.issue12000@psf.upfronthosting.co.za>


Nicolas Bareil <nico at chdir.org> added the comment:

Hello Antoine, Steffen,

You are absolutely right about removing the 'not san' part. Here is the
new patch, with tests :

diff -r c22d5b37f6a4 Lib/ssl.py
--- a/Lib/ssl.py        Fri May 06 09:31:02 2011 +0300
+++ b/Lib/ssl.py        Fri May 06 12:47:14 2011 +0200
@@ -122,8 +122,9 @@
             if _dnsname_to_pat(value).match(hostname):
                 return
             dnsnames.append(value)
-    if not san:
-        # The subject is only checked when subjectAltName is empty
+    if not dnsnames:
+        # The subject is only checked when there is no dNSName entry
+        # in subjectAltName
         for sub in cert.get('subject', ()):
             for key, value in sub:
                 # XXX according to RFC 2818, the most specific Common Name
diff -r c22d5b37f6a4 Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py      Fri May 06 09:31:02 2011 +0300
+++ b/Lib/test/test_ssl.py      Fri May 06 12:47:14 2011 +0200
@@ -277,6 +277,24 @@
                             (('organizationName', 'Google Inc'),))}
         fail(cert, 'mail.google.com')
 
+        # No DNS entry in subjectAltName but a commonName
+        cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT',
+                'subject': ((('countryName', 'US'),),
+                            (('stateOrProvinceName', 'California'),),
+                            (('localityName', 'Mountain View'),),
+                            (('commonName', 'mail.google.com'),)),
+                'subjectAltName': (('othername', 'blabla'), )}
+        ok(cert, 'mail.google.com')
+
+        # No DNS entry subjectAltName and no commonName
+        cert = {'notAfter': 'Dec 18 23:59:59 2099 GMT',
+                'subject': ((('countryName', 'US'),),
+                            (('stateOrProvinceName', 'California'),),
+                            (('localityName', 'Mountain View'),),
+                            (('organizationName', 'Google Inc'),)),
+                'subjectAltName': (('othername', 'blabla'),)}
+        fail(cert, 'google.com')
+
         # Empty cert / no cert
         self.assertRaises(ValueError, ssl.match_hostname, None, 'example.com')
         self.assertRaises(ValueError, ssl.match_hostname, {}, 'example.com')


Steffen, I will submit a bug report to Mercurial as soon as this patch is expected to be integrate in py3k.

----------
versions: +Python 3.4

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

From report at bugs.python.org  Fri May  6 13:03:03 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 06 May 2011 11:03:03 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1304679783.43.0.796649574573.issue10775@psf.upfronthosting.co.za>


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

New patch by Ezio looks good to me. Go ahead and commit. Please raise a separate issue for error reporting when invalid argument combinations are used. (i.e. additional keyword arguments but no callable.)

----------

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

From report at bugs.python.org  Fri May  6 13:22:43 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 06 May 2011 11:22:43 +0000
Subject: [issue11887] unittest fails on comparing str with bytes if python has
	the -bb option
In-Reply-To: <1303313753.3.0.8744280471.issue11887@psf.upfronthosting.co.za>
Message-ID: <1304680963.8.0.0302491707421.issue11887@psf.upfronthosting.co.za>


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

_baseAssertEqual should not unconditionally catch and ignore all BytesWarnings.

If tests raise warnings/exceptions because they are doing comparisons that raise warnings/exceptions then those tests should be fixed rather than just ignoring the warnings.

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

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

From report at bugs.python.org  Fri May  6 14:02:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2011 12:02:52 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <E1QIJk8-0006mu-Qz@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8fc801ca9ea1 by Ezio Melotti in branch 'default':
Issue #10775: assertRaises, assertRaisesRegex, assertWarns, and assertWarnsRegex now accept a keyword argument 'msg' when used as context managers.  Initial patch by Winston Ewert.
http://hg.python.org/cpython/rev/8fc801ca9ea1

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

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

From report at bugs.python.org  Fri May  6 14:07:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 12:07:26 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1304683646.4.0.287161725482.issue10775@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done, thanks for the patch!

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

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

From report at bugs.python.org  Fri May  6 14:17:05 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 12:17:05 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304684225.13.0.97713664554.issue11999@psf.upfronthosting.co.za>


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

Isn't this a bit out of scope for the mailbox module, though?  Mailbox is getting called at irregular intervals, and a clock monitor really wants to be a polling daemon of some sort, I think.  In which case a complete application system that used the mailbox library could adjust the _skewtime appropriately based on the output of a daemon, if it really cares that much.

I think we're well into YAGNI territory, though.  We are only concerned about how long one second is to the filesystem, and a filesystem that skews or jitters more than a tenth of a second over one second is probably pathological anyway.

As for the two second filesystem, my understanding is that is the FAT file system, and I say we just declare using maildir on FAT to be unsupported.  (But I suppose that should be documented).

(As a side note, atime on FAT has a resolution of 1 day, which kind of screws up your "new mail" signal....)

----------

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

From report at bugs.python.org  Fri May  6 14:25:57 2011
From: report at bugs.python.org (ivank)
Date: Fri, 06 May 2011 12:25:57 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>


New submission from ivank <bugs at ludios.org>:

Decoding a highly-nested object with json (_speedups enabled) can cause a segfault due to a stack overflow:

# python -c "import json; json.loads('[' * 100000 + '1' + ']' * 100000)"
zsh: segmentation fault  python -c "import json; json.loads('[' * 100000 + '1' + ']' * 100000)"

# python -c "import json; json.loads('{\"a\":' * 100000 + '1' + '}' * 100000)"
zsh: segmentation fault  python -c "import json; json.loads('{\"a\":' * 100000 + '1' + '}' * 100000)"

simplejson has the same problem:
https://github.com/simplejson/simplejson/pull/11

I've started on a fix (see patch at that URL), but it doesn't support customizing max_depth yet.

----------
components: Library (Lib)
messages: 135281
nosy: ivank
priority: normal
severity: normal
status: open
title: Decoding a highly-nested object with json (_speedups enabled) causes segfault
type: security
versions: Python 2.7

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

From report at bugs.python.org  Fri May  6 14:27:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 12:27:42 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304684862.97.0.753377935356.issue11999@psf.upfronthosting.co.za>


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

Oh, and to be clear: the problem wasn't that the one second interval was too short, the problem was that the times stamps of the files were being compared to the wrong check value (the system clock instead of their previous state).  The extra one tenth second is a "belt and suspenders" addition.

----------

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

From report at bugs.python.org  Fri May  6 14:28:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 12:28:42 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304684922.35.0.69438851534.issue11999@psf.upfronthosting.co.za>


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

I am open to the argument that we should make it two seconds and a bit to support FAT, but how many people are going to use maildir on FAT?

----------

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

From report at bugs.python.org  Fri May  6 14:31:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 12:31:09 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304685069.14.0.0434450832739.issue12017@psf.upfronthosting.co.za>


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


----------
components: +Extension Modules -Library (Lib)
nosy: +ezio.melotti
stage:  -> test needed
versions: +Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri May  6 14:32:19 2011
From: report at bugs.python.org (ivank)
Date: Fri, 06 May 2011 12:32:19 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304685139.03.0.567588229638.issue12017@psf.upfronthosting.co.za>


ivank <bugs at ludios.org> added the comment:

<ivan`> any opinions here on what the default max_depth should be? is there any safe number?
<ivan`> I'm curious as to how many C stack frames I can use after reaching the Python recursion limit
<ivan`> and what ulimit -s looks like on every platform
<Taggnostr> http://hg.python.org/cpython/file/tip/Lib/test/test_parser.py#l537
<Taggnostr> ivan`, maybe this is useful

----------

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

From report at bugs.python.org  Fri May  6 14:33:01 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 06 May 2011 12:33:01 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304685181.41.0.075425293147.issue12017@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

Why not use Py_EnterRecursiveCall?

----------
nosy: +alex

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

From report at bugs.python.org  Fri May  6 14:35:18 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 12:35:18 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304684225.13.0.97713664554.issue11999@psf.upfronthosting.co.za>
Message-ID: <20110506123510.GA6400@sherwood.local>


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

I like all kind of single-screw solutions.
And i feel a bit uncomfortable with your usual tightness.
(0.1 seconds - i mean, come on)

----------

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

From report at bugs.python.org  Fri May  6 14:41:02 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 12:41:02 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304684922.35.0.69438851534.issue11999@psf.upfronthosting.co.za>
Message-ID: <20110506124052.GA11620@sherwood.local>


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

> how many people are going to use maildir on FAT?

Dunno.
But it's maybe the lowest common denominator of mountable
readwrite filesystems.  Except for that MacBook i always had
a shared FAT partition on my private PCs.

----------

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

From report at bugs.python.org  Fri May  6 14:46:49 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 12:46:49 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1304610424.6.0.254596604566.issue11935@psf.upfronthosting.co.za>
Message-ID: <20110506124640.GB11620@sherwood.local>


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

@david: note i got stuck on updating my patch for mailbox.py and
switched to do test_mmap.py instead, so that i don't know wether
i will be able to finish it today.  Is it really true that
mailbox.py even writes mailboxes without locking in case of an
appending write?  So i really have to look at that before i will
proceed and write the patch.

----------

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

From report at bugs.python.org  Fri May  6 14:56:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 12:56:19 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304686579.89.0.184202929833.issue11999@psf.upfronthosting.co.za>


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

All right, let's make it two seconds and a bit, then.

Why do you think a tenth of second is too small?  A clock with a skew of half that much would be badly broken.

----------

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

From report at bugs.python.org  Fri May  6 14:59:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 12:59:07 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304686747.16.0.0395255848359.issue12017@psf.upfronthosting.co.za>


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


----------
nosy: +barry
priority: normal -> high
stage: test needed -> needs patch
versions: +Python 2.6

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

From report at bugs.python.org  Fri May  6 15:08:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 06 May 2011 13:08:20 +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: <1304687300.2.0.796650121298.issue11898@psf.upfronthosting.co.za>


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

Hello Bernhard, 

I tried to a POST of JPEG file, through urllib2 (which internally uses httplib) and goes through the code that you pointed out and I don't face any problem. I am able to POST binaries using httplib.

I am also surprised at UnicodeDecodeError which is being raised. The POST data is string (8-bit strings) in Python2.7 and the portion of code will have no problem in creating the content.

You will get UnicodeDecodeError, only if you explicitly pass a Unicode Object as Data and never when you pass string or binary string.

Perhaps mechanize is doing something wrong here and sending a Unicode object.

So, this really does not look like a bug to me.

(Also a note on patch. The patch tries to silence the error, which is wrong thing to do).

If you can provide a simple snippet to reproduce this error, feel free reopen this again. I am closing this as 'works for me'.

Thanks.

----------
assignee:  -> orsenthil
resolution:  -> works for me
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri May  6 15:15:03 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 13:15:03 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304686579.89.0.184202929833.issue11999@psf.upfronthosting.co.za>
Message-ID: <20110506131452.GA19269@sherwood.local>


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

I agree that it's fun to see pieces of code interacting like gears
in a transmission, but often it gets ugly due to the noise from
the outside which requires to add ugly fuzziness or honour stupid
design decisions.
Maybe an environment variable like PYMAILBOX_SKEW and then one
could run test_mailbox.py and see if it works for 0.01?? :)

----------

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

From report at bugs.python.org  Fri May  6 15:26:24 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 13:26:24 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1304688384.97.0.216908640682.issue9670@psf.upfronthosting.co.za>


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

Version 4 of the patch has two changes w.r.t version 3:

* Increase the stack size on OSX to ensure that tests pass with
  --with-pydebug

* Only test the recursion behavior on OSX (where we know the bug is
  fixed)

----------
Added file: http://bugs.python.org/file21907/issue9670-v4.patch

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

From report at bugs.python.org  Fri May  6 15:32:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2011 13:32:52 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <E1QIL9G-0006M6-KG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d4c2a99d1bad by Antoine Pitrou in branch '3.2':
Issue #12000: When a SSL certificate has a subjectAltName without any
http://hg.python.org/cpython/rev/d4c2a99d1bad

New changeset 1b37827984ba by Antoine Pitrou in branch 'default':
Issue #12000: When a SSL certificate has a subjectAltName without any
http://hg.python.org/cpython/rev/1b37827984ba

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

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

From report at bugs.python.org  Fri May  6 15:37:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 13:37:29 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304689049.51.0.690690266408.issue12000@psf.upfronthosting.co.za>


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

Patch committed in 3.2 and 3.x, thank you!

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

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

From report at bugs.python.org  Fri May  6 16:00:42 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 06 May 2011 14:00:42 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304690442.62.0.0076075282365.issue10684@psf.upfronthosting.co.za>


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

test_move_dir_caseinsensitive is failing on some of the XP buildbots:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4514
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/2696
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.2/builds/239

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 16:11:01 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 14:11:01 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304691061.07.0.163212898437.issue10684@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That's rather annoying. I'm reopening the issue because of this.

I'm looking into the issue and will revert when I cannot find a solution soon.

----------
resolution: fixed -> accepted
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 16:15:59 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 06 May 2011 14:15:59 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304691359.4.0.933126690557.issue12000@psf.upfronthosting.co.za>


Changes by Mads Kiilerich <mads at kiilerich.com>:


----------
nosy: +kiilerix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12000>
_______________________________________

From report at bugs.python.org  Fri May  6 16:34:45 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 14:34:45 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304692485.09.0.31472123634.issue10684@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This seems to be a bug in ntpath.samefile, in particular in this code:


# determine if two files are in fact the same file
try:
    # GetFinalPathNameByHandle is available starting with Windows 6.0.
    # Windows XP and non-Windows OS'es will mock _getfinalpathname.
    if sys.getwindowsversion()[:2] >= (6, 0):
        from nt import _getfinalpathname
    else:
        raise ImportError
except (AttributeError, ImportError):
    # On Windows XP and earlier, two files are the same if their absolute
    # pathnames are the same.
    # Non-Windows operating systems fake this method with an XP
    # approximation.
    def _getfinalpathname(f):
        return abspath(f)

def samefile(f1, f2):
    "Test whether two pathnames reference the same actual file"
    return _getfinalpathname(f1) == _getfinalpathname(f2)

Python2 doesn't have ntpath.samefile and shutil then falls back to comparing "os.path.normcase(os.path.abspath(src))" with the same transformation of dst.

On XP _getfinalpath doesn't call os.path.normcase, hence it doesn't notice that "a" and "A" refer to the same file (on all common NT filesystems)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 16:37:42 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 14:37:42 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304692662.48.0.961462153465.issue10684@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm not sure what the right course of action is, revert my patch try to get ntpath.samefile fixed and then reapply my patch or something else?

ntpath.samefile is definitely broken on XP:

* Create a file "a.txt"
* Start python3.2
  >>> os.path.samefile("a.txt", "A.TXT")
  False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 16:41:36 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 06 May 2011 14:41:36 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304692896.12.0.0145108580736.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

The semantics the docs suggest for index fields (namely that whatever is in the index field is just passed to getitem) do seem to be right, no other processing is done here, for instance:

>>> d = {"{0}":"hi"}
>>> "{0[{0}]}".format(d)
'hi'
>>> import string
>>> list(string.Formatter().parse("{0[{0}]}"))
[('', '0[{0}]', '', None)]
>>> 

Which is what you'd expect, but makes me think that treating "!" and ":" in the index field separately is definitely wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Fri May  6 16:46:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 06 May 2011 14:46:40 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304693200.47.0.246230382311.issue10684@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

On XP, os.path.samefile is really "os.path.abspath(x) == os.path.abspath(y)", which does not work correctly with different cases. We could add a ".lower()" to line 657 of Lib/ntpath.py so the abspath is always returned in lower, so the XP version of samefile compares two lower case strings.

On versions after XP, this isn't an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 16:50:18 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 14:50:18 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304693418.9.0.265460165756.issue10684@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch seems to fix ntpath.samefile (at least for the shutils tests, I haven't run a full testsuite and cannot build python on a windows machine anyway)

----------
Added file: http://bugs.python.org/file21908/npath-fix.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 16:51:59 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 06 May 2011 14:51:59 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304693519.87.0.774830686397.issue10684@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I don't have time to test it at the moment, but it seems fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 16:54:50 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 06 May 2011 14:54:50 +0000
Subject: [issue11178] Running tests inside a package by module name fails
In-Reply-To: <1297369148.53.0.82343889297.issue11178@psf.upfronthosting.co.za>
Message-ID: <1304693690.23.0.956094754019.issue11178@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This isn't reproducable (any more?) on Python 2.7, but is on Python 3.2.

Running "python -m unittest package" doesn't find tests in submodules, but without running full discovery even when passed an explicit module name I don't think that is avoidable.

----------
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11178>
_______________________________________

From report at bugs.python.org  Fri May  6 16:56:57 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 14:56:57 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304693817.51.0.806523569806.issue10684@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm currrently running 'python -mtest.regrtest -uall' on an XP machine where I've applied my test to a binary install of 3.2.

I'll apply my patch if that testrun indicates that I don't introduce other problems, and I'll revert my shutil patch when the change to ntpath.samefile isn't fine after call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 17:11:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2011 15:11:51 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <E1QIMh4-00077j-7o@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 011e4bb8b933 by Ronald Oussoren in branch '3.2':
ntpath.samefile fails to detect that "A.TXT" and "a.txt" refer to the same file on Windows XP.
http://hg.python.org/cpython/rev/011e4bb8b933

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 17:12:41 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 15:12:41 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304694761.38.0.0196816427902.issue10684@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've committed my fix for ntpath.samefile for 3.3 and 3.2.

I've also filed a new issue because ntpath.samefile has no unittests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 17:12:50 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 15:12:50 +0000
Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile
In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>
Message-ID: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Python 3.2 introduced ntpath.samefile, but the implementation is not tested in test_ntpath.py. The same seems true of ntpath.sameopenfile.

As noted in #10684 ntpath.samefile is broken on XP, which would have been caught by unittest. I've committed a fix for that particular bug, but haven't added unittests.

----------
components: Windows
keywords: easy
messages: 135307
nosy: ronaldoussoren
priority: low
severity: normal
stage: test needed
status: open
title: No tests for ntpath.samefile, ntpath.sameopenfile
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12018>
_______________________________________

From report at bugs.python.org  Fri May  6 17:13:14 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 May 2011 15:13:14 +0000
Subject: [issue10684] Folders get deleted when trying to change case with
	shutil.move (case insensitive file systems only)
In-Reply-To: <1292149124.13.0.45494559671.issue10684@psf.upfronthosting.co.za>
Message-ID: <1304694794.24.0.375517361311.issue10684@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10684>
_______________________________________

From report at bugs.python.org  Fri May  6 17:13:45 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 06 May 2011 15:13:45 +0000
Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile
In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>
Message-ID: <1304694825.56.0.459021062849.issue12018@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/issue12018>
_______________________________________

From report at bugs.python.org  Fri May  6 17:23:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 15:23:54 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304695434.9.0.706915052029.issue12017@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12017>
_______________________________________

From report at bugs.python.org  Fri May  6 17:33:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 15:33:08 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1304643247.49.0.687409902496.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110506153255.GA66752@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Fri,  6 May 2011 02:54:07 +0200, Nadeem Vawda wrote:
> I think so. [.]
> it turns out that the OS X sparsefile crash is also covered by
> LargeMmapTests.test_large_offset() in test_mmap [!!!]. [.]

So i followed your suggestion and did not do something on zlib no
more.  Even if that means that there is no test which checksums an
entire superlarge mmap() region.
Instead i've changed/added test cases in test_mmap.py:

- Removed all context-manager usage from LargeMmapTests().
  This feature has been introduced in 3.2 and is already tested
  elsewhere.  Like this the test is almost identical on 2.7 and 3.x.
- I've dropped _working_largefile().  This creates a useless large
  file only to unlink it directly.  Instead the necessary try:catch:
  is done directly in the tests.
- (Directly testing after .flush() without reopening the file.)
- These new tests don't run on 32 bit.

May the juice be with you

----------
Added file: http://bugs.python.org/file21909/11277-test_mmap.1.py
Added file: http://bugs.python.org/file21910/11277-test_mmap-27.1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________
-------------- next part --------------
diff --git a/Lib/test/test_mmap.py b/Lib/test/test_mmap.py
--- a/Lib/test/test_mmap.py
+++ b/Lib/test/test_mmap.py
@@ -1,4 +1,5 @@
-from test.support import TESTFN, run_unittest, import_module, unlink, requires
+from test.support import TESTFN, run_unittest, import_module, unlink
+from test.support import requires, _4G
 import unittest
 import os
 import re
@@ -662,44 +663,87 @@
     def tearDown(self):
         unlink(TESTFN)
 
-    def _working_largefile(self):
-        # Only run if the current filesystem supports large files.
-        f = open(TESTFN, 'wb', buffering=0)
+    def _test_splice(self, f, i):
+        # Test splicing with pages around "critical" values in respect to
+        # memory management
+        # Issue 11277: does mmap() force materialization of backing store?
+        m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
         try:
-            f.seek(0x80000001)
-            f.write(b'x')
-            f.flush()
-        except (IOError, OverflowError):
-            raise unittest.SkipTest("filesystem does not have largefile support")
+            # Memory page before xy
+            self.assertEqual(m[i+0:i+2], b'  ')
+            # Memory page after xy
+            self.assertEqual(m[i+10:i+12], b'  ')
+            # Cross pages
+            self.assertEqual(m[i+2:i+10], b'DEARdear')
         finally:
-            f.close()
-            unlink(TESTFN)
+            m.close()
 
-    def test_large_offset(self):
+    def _test_subscr(self, f, idx, expect):
+        # Test subscript for critical values like INT32_MAX, UINT32_MAX
+        m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
+        try:
+            self.assertEqual(m[idx], expect)
+        finally:
+            m.close()
+
+    @unittest.skipUnless(sys.maxsize > _4G, "Can't run on a 32-bit system.")
+    def test_around_32bit_sbitflip(self):
+        start = 0x7FFFFFFA
         if sys.platform[:3] == 'win' or sys.platform == 'darwin':
             requires('largefile',
-                'test requires %s bytes and a long time to run' % str(0x180000000))
-        self._working_largefile()
-        with open(TESTFN, 'wb') as f:
-            f.seek(0x14FFFFFFF)
-            f.write(b" ")
+                     'test requires %s bytes and a long time to run' %
+                     str(start+12))
+        with open(TESTFN, 'w+b') as f:
+            try:
+                f.seek(start)
+                f.write(b'  DEARdear  ')
+                f.flush()
+            except (IOError, OverflowError):
+                raise unittest.SkipTest('filesystem does not have largefile '
+                                        'support')
+            self._test_splice(f, start)
+            self._test_subscr(f, start+len(b'  DEA'), ord(b'R'))
+            self._test_subscr(f, start+len(b'  DEARdea'), ord(b'r'))
+        unlink(TESTFN)
 
-        with open(TESTFN, 'rb') as f:
-            with mmap.mmap(f.fileno(), 0, offset=0x140000000, access=mmap.ACCESS_READ) as m:
-                self.assertEqual(m[0xFFFFFFF], 32)
+    @unittest.skipUnless(sys.maxsize > _4G, "Can't run on a 32-bit system.")
+    def test_around_32bit_excess(self):
+        start = 0xFFFFFFFA
+        if sys.platform[:3] == 'win' or sys.platform == 'darwin':
+            requires('largefile',
+                     'test requires %s bytes and a long time to run' %
+                     str(start+12))
+        with open(TESTFN, 'w+b') as f:
+            try:
+                f.seek(start)
+                f.write(b'  DEARdear  ')
+                f.flush()
+            except (IOError, OverflowError):
+                raise unittest.SkipTest('filesystem does not have largefile '
+                                        'support')
+            self._test_splice(f, start)
+            self._test_subscr(f, start+len(b'  DEA'), ord(b'R'))
+            self._test_subscr(f, start+len(b'  DEARdea'), ord(b'r'))
+        unlink(TESTFN)
 
     def test_large_filesize(self):
         if sys.platform[:3] == 'win' or sys.platform == 'darwin':
             requires('largefile',
                 'test requires %s bytes and a long time to run' % str(0x180000000))
-        self._working_largefile()
         with open(TESTFN, 'wb') as f:
-            f.seek(0x17FFFFFFF)
-            f.write(b" ")
+            try:
+                f.seek(0x17FFFFFFF)
+                f.write(b' ')
+            except (IOError, OverflowError):
+                raise unittest.SkipTest('filesystem does not have largefile '
+                                        'support')
 
         with open(TESTFN, 'rb') as f:
-            with mmap.mmap(f.fileno(), 0x10000, access=mmap.ACCESS_READ) as m:
+            m = mmap.mmap(f.fileno(), 0x10000, access=mmap.ACCESS_READ)
+            try:
                 self.assertEqual(m.size(), 0x180000000)
+            finally:
+                m.close()
 
 
 def test_main():
-------------- next part --------------
diff --git a/Lib/test/test_mmap.py b/Lib/test/test_mmap.py
--- a/Lib/test/test_mmap.py
+++ b/Lib/test/test_mmap.py
@@ -1,4 +1,5 @@
-from test.test_support import TESTFN, run_unittest, import_module, unlink, requires
+from test.test_support import TESTFN, run_unittest, import_module, unlink
+from test.test_support import requires, _4G
 import unittest
 import os, re, itertools, socket, sys
 
@@ -644,43 +645,80 @@
     def tearDown(self):
         unlink(TESTFN)
 
-    def _working_largefile(self):
-        # Only run if the current filesystem supports large files.
-        f = open(TESTFN, 'wb', buffering=0)
+    def _test_splice(self, f, i):
+        # Test splicing with pages around "critical" values in respect to
+        # memory management
+        # Issue 11277: does mmap() force materialization of backing store?
+        m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
         try:
-            f.seek(0x80000001)
-            f.write(b'x')
-            f.flush()
-        except (IOError, OverflowError):
-            raise unittest.SkipTest("filesystem does not have largefile support")
+            # Memory page before xy
+            self.assertEqual(m[i+0:i+2], b'  ')
+            # Memory page after xy
+            self.assertEqual(m[i+10:i+12], b'  ')
+            # Cross pages
+            self.assertEqual(m[i+2:i+10], b'DEARdear')
         finally:
-            f.close()
-            unlink(TESTFN)
+            m.close()
 
-    def test_large_offset(self):
+    def _test_subscr(self, f, idx, expect):
+        # Test subscript for critical values like INT32_MAX, UINT32_MAX
+        m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
+        try:
+            self.assertEqual(m[idx], expect)
+        finally:
+            m.close()
+
+    @unittest.skipUnless(sys.maxsize > _4G, "Can't run on a 32-bit system.")
+    def test_around_32bit_sbitflip(self):
+        start = 0x7FFFFFFA
         if sys.platform[:3] == 'win' or sys.platform == 'darwin':
             requires('largefile',
-                'test requires %s bytes and a long time to run' % str(0x180000000))
-        self._working_largefile()
-        with open(TESTFN, 'wb') as f:
-            f.seek(0x14FFFFFFF)
-            f.write(b" ")
+                     'test requires %s bytes and a long time to run' %
+                     str(start+12))
+        with open(TESTFN, 'w+b') as f:
+            try:
+                f.seek(start)
+                f.write(b'  DEARdear  ')
+                f.flush()
+            except (IOError, OverflowError):
+                raise unittest.SkipTest('filesystem does not have largefile '
+                                        'support')
+            self._test_splice(f, start)
+            self._test_subscr(f, start+len(b'  DEA'), b'R')
+            self._test_subscr(f, start+len(b'  DEARdea'), b'r')
+        unlink(TESTFN)
 
-        with open(TESTFN, 'rb') as f:
-            m = mmap.mmap(f.fileno(), 0, offset=0x140000000, access=mmap.ACCESS_READ)
+    @unittest.skipUnless(sys.maxsize > _4G, "Can't run on a 32-bit system.")
+    def test_around_32bit_excess(self):
+        start = 0xFFFFFFFA
+        if sys.platform[:3] == 'win' or sys.platform == 'darwin':
+            requires('largefile',
+                     'test requires %s bytes and a long time to run' %
+                     str(start+12))
+        with open(TESTFN, 'w+b') as f:
             try:
-                self.assertEqual(m[0xFFFFFFF], b" ")
-            finally:
-                m.close()
+                f.seek(start)
+                f.write(b'  DEARdear  ')
+                f.flush()
+            except (IOError, OverflowError):
+                raise unittest.SkipTest('filesystem does not have largefile '
+                                        'support')
+            self._test_splice(f, start)
+            self._test_subscr(f, start+len(b'  DEA'), b'R')
+            self._test_subscr(f, start+len(b'  DEARdea'), b'r')
+        unlink(TESTFN)
 
     def test_large_filesize(self):
         if sys.platform[:3] == 'win' or sys.platform == 'darwin':
             requires('largefile',
                 'test requires %s bytes and a long time to run' % str(0x180000000))
-        self._working_largefile()
         with open(TESTFN, 'wb') as f:
-            f.seek(0x17FFFFFFF)
-            f.write(b" ")
+            try:
+                f.seek(0x17FFFFFFF)
+                f.write(b' ')
+            except (IOError, OverflowError):
+                raise unittest.SkipTest('filesystem does not have largefile '
+                                        'support')
 
         with open(TESTFN, 'rb') as f:
             m = mmap.mmap(f.fileno(), 0x10000, access=mmap.ACCESS_READ)

From report at bugs.python.org  Fri May  6 17:34:51 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 15:34:51 +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: <1304696091.06.0.858340797571.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21869/11277-27.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Fri May  6 17:35:11 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 06 May 2011 15:35:11 +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: <1304696111.0.0.298246709354.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21885/11277-27.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Fri May  6 17:35:12 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 06 May 2011 15:35:12 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304696112.22.0.215171112489.issue12000@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

In my opinion the RFCs are a bit unclear about how iPAddress subjectAltNames should be handled. (I also don't know if Python currently do the right thing by accepting and matching IP addresses if specified in commonName.)

Until now Python failed to the safe side by not matching on subjectAltName iPAddress but also not falling back to commonName if they were specified. AFAICS, with this change it is possible to create strange certificates that Python would accept when an IP address matched commonName but other implementations would reject because of iPAddress mismatch.

That is probably not a real problem, but I wanted to point it out as the biggest issue I could find with this fix. Nice catch.

We could perhaps add IP addresses to dnsnames even though we don't match on them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12000>
_______________________________________

From report at bugs.python.org  Fri May  6 17:43:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 15:43:24 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304696604.76.0.121881969133.issue9971@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+        if (n <= 0) {
+            if (written > 0 || n == 0)
+                break;
+            if (n == -2) {
+                Py_INCREF(Py_None);
+                res = Py_None;
+            }
+            goto end;
+        }

I think the logic is flawed: if n = -1 and written is > 0, the error will be silenced.
Other than that, the patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Fri May  6 18:01:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:01:13 +0000
Subject: [issue11963] Use real assert* for test_trigger_memory_error
	(test_parser)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1304697673.39.0.0361926662612.issue11963@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IIRC the code uses C stdio to print its error message, not Python APIs, so this would explain why replacing sys.stdout doesn?t work.

There?s another test that spits things to stdout: test_subprocess.  Should I clean it up too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11963>
_______________________________________

From report at bugs.python.org  Fri May  6 18:02:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:02:32 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1304697752.23.0.999862786012.issue11995@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Isn?t the root problem that pydoc uses import rather than imp or PEP 302 things?  We could change that.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11995>
_______________________________________

From report at bugs.python.org  Fri May  6 18:04:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:04:46 +0000
Subject: [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1304697886.48.0.140150809721.issue11762@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The Python Insider blog has a nice phrasing: ?The AST module exposes a constant, ``ast.__version__``, which provides a means for user code to vary its behaviour depending on the version of the AST it encounters.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11762>
_______________________________________

From report at bugs.python.org  Fri May  6 18:08:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:08:27 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I was stealing importlib?s test/__main__ file for packaging (thanks!) and I noticed this bug thanks to pyflakes: ?sep? is undefined.  It looks like the bug hasn?t been noticed because it?s in a dead block that depends on __file__ containing '__pycache__'.  Is this a leftover from a previous version of the PEP without __file__/__cached__ distinction?  Or maybe __file__ is set to the pyc file for pyc-only imports?

----------
components: Tests
messages: 135314
nosy: barry, brett.cannon, eric.araujo
priority: normal
severity: normal
status: open
title: Dead or buggy code in importlib.test.__main__
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12019>
_______________________________________

From report at bugs.python.org  Fri May  6 18:11:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 16:11:02 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304698262.37.0.537087217829.issue12017@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch fixes the issues. The patch includes 6 tests that caused a segfault and that now raise a "RuntimeError: maximum recursion depth exceeded" error, matching the behavior of the Python version.

The recursion happen because scan_once_str/unicode might call _parse_object_str/unicode (for objects/dicts) and _parse_array_str/unicode (for arrays/lists), and these functions might call scan_once_str again for their inner elements.
To fix the problem I added Py_Enter/LeaveRecursiveCall around the calls to _parse_object_str and _parse_array_str in scan_once_str/unicode.

For some reason the message raised with json.loads('{"a":' * 100000 + '1' + '}' * 100000), is a generic "maximum recursion depth exceeded while calling a Python object", but that's probably not too important.
The other messages work fine.

----------
keywords: +patch
nosy: +benjamin.peterson, georg.brandl
priority: high -> release blocker
stage: needs patch -> commit review
Added file: http://bugs.python.org/file21911/issue12017.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12017>
_______________________________________

From report at bugs.python.org  Fri May  6 18:12:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 16:12:25 +0000
Subject: [issue12001] Extend json.dumps to handle N-triples strings
In-Reply-To: <1304518731.8.0.661491806451.issue12001@psf.upfronthosting.co.za>
Message-ID: <1304698345.31.0.72785016276.issue12001@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure there's any sense in trying to bend the json module into producing other formats.

----------
nosy: +pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12001>
_______________________________________

From report at bugs.python.org  Fri May  6 18:30:09 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 06 May 2011 16:30:09 +0000
Subject: [issue12001] Extend json.dumps to handle N-triples strings
In-Reply-To: <1304518731.8.0.661491806451.issue12001@psf.upfronthosting.co.za>
Message-ID: <1304699409.47.0.510289265823.issue12001@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Feature creep would not be good for the json module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12001>
_______________________________________

From report at bugs.python.org  Fri May  6 18:35:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:35:05 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1304699705.83.0.113184161284.issue11977@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Benjamin: In 2.7, long implements those ABCs too.  I have added it to the doc in a local commit, I?ll push when I can.

Jonas: Does the commit fix your use case?  The attributes are now documented in the sense that a human can find them, but can Sphinx?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11977>
_______________________________________

From report at bugs.python.org  Fri May  6 18:36:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:36:19 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1304699779.11.0.190535316935.issue11977@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW: If not, you can always use things like :attr:`int.real <numbers.Integral.real>` (real target in angle brackets, rest is text to display) but it?s a bit unwieldy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11977>
_______________________________________

From report at bugs.python.org  Fri May  6 18:39:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:39:07 +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: <1304699947.57.0.683232879729.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Intersphinx-ing of int, list, float, ... should work with
> ":class:`int`" (list, float, ...).

Is this a problem in our markup or a bug in intersphinx?  IIRC, you can use func, class, mod, method or what you want, all these roles look up objects in the same way.

> Also, intersphinx-ing list methods, e.g. ":meth:`list.insert`",
> should work.

If this work within one documentation set (as I believe it does) but not with intersphinx, it?s an intersphinx bug which should be reported to the Sphinx bug tracker on bitbucket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Fri May  6 18:41:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:41:54 +0000
Subject: [issue11983] Inconsistent hash and comparison for code objects
In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za>
Message-ID: <1304700114.71.0.694094128214.issue11983@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What fix would you propose?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11983>
_______________________________________

From report at bugs.python.org  Fri May  6 18:50:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2011 16:50:02 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <E1QIOE1-0006vp-1z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset aba7d1f2d2a9 by Antoine Pitrou in branch 'default':
Issue #8808: The IMAP4_SSL constructor now allows passing an SSLContext
http://hg.python.org/cpython/rev/aba7d1f2d2a9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Fri May  6 18:51:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:51:08 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1304700668.39.0.947649784762.issue11964@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will fix this.

Prashanth Raghu: (sorry to call you by your full name, which is not very nice in my language, but I?m not sure which is your first name) ?The .rst file that was downloaded as of 30-04-2011 (dd-mm-yyyy) had the updated doc?: Yes, I saw that, but I reported a lack of versionchanged information (see example near the top of http://docs.python.org/dev/library/site).

----------
assignee: docs at python -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11964>
_______________________________________

From report at bugs.python.org  Fri May  6 18:52:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 16:52:19 +0000
Subject: [issue8808] imaplib should support SSL contexts
In-Reply-To: <1274717637.39.0.0073929793702.issue8808@psf.upfronthosting.co.za>
Message-ID: <1304700739.87.0.579118152667.issue8808@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you! I've tweaked the patch slightly (mostly cosmetics (*)) and committed it to 3.3. I've left out the poplib doc changes, they could be committed separately.

(*) 80-line character limit, calling logout() on the test server

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8808>
_______________________________________

From report at bugs.python.org  Fri May  6 18:53:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:53:24 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <1304700804.99.0.392688694396.issue11968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Can you tell more about the bug you perceive?  The doc and code for wsgiref were carefully updated to play well with Python 3 clean bytes/characters distinction, so I?m surprised by this bug report.  Maybe you mistakenly tried the example with a Python 2.x version?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11968>
_______________________________________

From report at bugs.python.org  Fri May  6 18:56:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 16:56:57 +0000
Subject: [issue11989] deprecate shutil.copy2
In-Reply-To: <1304457480.12.0.859066442239.issue11989@psf.upfronthosting.co.za>
Message-ID: <1304701017.09.0.597013572589.issue11989@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Could you elaborate a bit on the rational for the change?  Aesthetics are usually not sufficient to change things; on the other hand, use of simplicity is a goal.

Is is easier to remember two functions for two uses or to have one function with a parameter?  Are users confused by the two functions with unhelpful names?  These are the kinds of questions to answer before considering breaking everyone?s code with a deprecation and removal.

Would you be willing to raise the issue on the python-ideas mailing list to get feedback?  Thanks in advance.

----------
nosy: +eric.araujo, rhettinger
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11989>
_______________________________________

From report at bugs.python.org  Fri May  6 18:58:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 16:58:19 +0000
Subject: [issue6116] frame.f_locals keeps references to things for too long
In-Reply-To: <1304621159.79.0.814665093364.issue6116@psf.upfronthosting.co.za>
Message-ID: <1304701096.3520.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 05 mai 2011 ? 18:45 +0000, Facundo Batista a ?crit :
> 
> Antoine, to see if I understood correctly... if we build the dict, and
> just return it but don't save it in the frame, this leak would be
> solved? (yes, it'd be slower because everytime it's asked, it'd need
> to be built again)

I would let Jean-Paul confirm the answer, but: yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6116>
_______________________________________

From report at bugs.python.org  Fri May  6 19:00:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:00:56 +0000
Subject: [issue12001] Extend json.dumps to handle N-triples strings
In-Reply-To: <1304518731.8.0.661491806451.issue12001@psf.upfronthosting.co.za>
Message-ID: <1304701256.8.0.0425465973879.issue12001@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed.  The purpose of the json module is clearly defined, and there is room for other modules to address other problems (like yaml).  It should be easy to write a Python function to convert a string to its N-triples serialization.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12001>
_______________________________________

From report at bugs.python.org  Fri May  6 19:02:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:02:28 +0000
Subject: [issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
In-Reply-To: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>
Message-ID: <1304701348.08.0.974480359642.issue12002@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  If you would like to turn your suggestion into a diff file (see guidelines at http://docs.python.org/devguide) containing the code change and a test, you could get into the Misc/ACKS file and get eternal glory :)

----------
nosy: +eric.araujo
stage:  -> needs patch
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12002>
_______________________________________

From report at bugs.python.org  Fri May  6 19:04:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:04:18 +0000
Subject: [issue12007] Console commands won't work
In-Reply-To: <1304592366.23.0.247868928288.issue12007@psf.upfronthosting.co.za>
Message-ID: <1304701458.03.0.954258058454.issue12007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Definitely looks like a shell, libcurses or readline configuration issue, sorry.  Please reopen this bug if you have new information contradicting our conclusion.

----------
nosy: +eric.araujo
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12007>
_______________________________________

From report at bugs.python.org  Fri May  6 19:04:34 2011
From: report at bugs.python.org (John O'Connor)
Date: Fri, 06 May 2011 17:04:34 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304701474.35.0.488407151594.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

Good catch. v3 attached.

----------
Added file: http://bugs.python.org/file21912/buffered_readinto3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Fri May  6 19:04:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:04:48 +0000
Subject: [issue12008] HtmlParser non-strict goes wrong with unquoted attributes
In-Reply-To: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za>
Message-ID: <1304701488.64.0.0739802802721.issue12008@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, r.david.murray
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12008>
_______________________________________

From report at bugs.python.org  Fri May  6 19:05:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:05:52 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1304701552.55.0.808836399877.issue12009@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Would you like to submit a patch?  If so, guidelines are on http://docs.python.org/devguide

----------
nosy: +eric.araujo
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Fri May  6 19:07:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:07:12 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304701632.68.0.80149328491.issue12012@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/issue12012>
_______________________________________

From report at bugs.python.org  Fri May  6 19:10:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:10:12 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304701812.97.0.525779561152.issue12012@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The original bug requesting that SSLv2 be disabled is #589706; the updated openssl package with this change is in Debian unstable and testing now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Fri May  6 19:11:41 2011
From: report at bugs.python.org (Jonas H.)
Date: Fri, 06 May 2011 17:11:41 +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: <1304701901.56.0.242773209884.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

> Is this a problem in our markup or a bug in intersphinx?

It's a markup problem -- those types are documented as functions, using the :func: role/`.. func::` directive.

It's not only a markup mismatch but, strictly speaking, it's *wrong* documentation: str, int, ... aren't functions, they're *classes* and should be documented as such. It's a bit odd to search for information on the str *class* in the list of built-in *functions*.


> If this work within one documentation set (as I believe it does)

It does not. For example, in http://docs.python.org/library/functions.html#max there's a reference to list.sort using :meth:`list.sort` but no link could be generated. How could it possibly work without decent documentation about the list data type?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Fri May  6 19:12:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:12:03 +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: <1304701923.42.0.535774173281.issue12013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks like a compilation problem.  Did you install that Python yourself?  Can you run the test suite to see if there are problems with the _socket module?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Fri May  6 19:13:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:13:17 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304701997.87.0.0774900355393.issue12014@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Fri May  6 19:15:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:15:35 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304702135.09.0.797612524256.issue12015@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FWIW: Conformity with popular systems is not a goal.

----------
nosy: +eric.araujo
versions:  -Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Fri May  6 19:15:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:15:59 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304702159.22.0.223945320668.issue12015@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Fri May  6 19:16:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:16:42 +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: <1304702202.72.0.877583782411.issue12016@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +haypo, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Fri May  6 19:18:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:18:45 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1304702325.74.0.402164186031.issue12003@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi.  Python 2.6 is in security mode, its documentation is not updated nor released anymore.  Is this bug present in the documentation of 2.7 or 3.x versions?

----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Fri May  6 19:22:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:22:59 +0000
Subject: [issue11984] Wrong "See also" in symbol and token module docs
In-Reply-To: <1304405152.56.0.259676009595.issue11984@psf.upfronthosting.co.za>
Message-ID: <1304702579.08.0.404328843335.issue11984@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IIUC, the parser and token module somehow can be used together.  If so, the interlinks are okay, provided the text is revised to remove mention of the ?second example?.  If I?m wrong, let?s remove the link.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11984>
_______________________________________

From report at bugs.python.org  Fri May  6 19:23:44 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2011 17:23:44 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304702624.99.0.124547175882.issue12014@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

> but makes me think that treating "!" and ":" in the index field separately is definitely wrong.

But it doesn't know they're in an index field when it's doing the parsing for ':' or '!'.

It might be possible to change this so that the field name is fully parsed first, but I'm not sure the benefit would justify the effort. What's your use case where you need this feature?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Fri May  6 19:23:49 2011
From: report at bugs.python.org (alejandro david weil)
Date: Fri, 06 May 2011 17:23:49 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1304702629.23.0.186911859075.issue12003@psf.upfronthosting.co.za>


alejandro david weil <tenuki at gmail.com> added the comment:

Yes it is. I copied both versions but forgot to specify the second is in 2.7.

This is read in the current (2.7) documentation:
# from: http://docs.python.org/library/functions.html?highlight=xrange#xrange
islice(count(start, step), (stop-start+step-1)//step)

and test_xrange.py shows the output of this code against range(). The code includes 2 samples of parameters which gives the unexpected results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Fri May  6 19:26:56 2011
From: report at bugs.python.org (Jonas H.)
Date: Fri, 06 May 2011 17:26:56 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1304702816.91.0.0778751980185.issue11977@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

It doesn't. Sphinx still can't make any links, which btw also means that it's impossible to reference those methods within the Python documentation.

Also I want to point out that I find the information very hard to find as a human. The fact that integers are based on `numbers.Number` is -- at this point in time where 95% of all Python developers don't know about the `numbers` module or abstract base classes in general -- an implementation detail and as such should not affect the way `int` is documented.

I propose to have decent class references for int, str, ... similar to the reference for dict -- that is, document all attributes and methods in one place and make them referencable. For those who want to deep-dive into CPython internals, a note about those functionality actually being implemented in ABCs could be added.

(But I think that's out of scope for this ticket. I could open a new one if anyone agrees with me... :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11977>
_______________________________________

From report at bugs.python.org  Fri May  6 19:31:30 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 06 May 2011 17:31:30 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1304703090.31.0.998138950127.issue11977@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reopening, it makes sense to have everything available for linking.

(Even if they are quite obscure attributes.)

----------
nosy: +georg.brandl
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11977>
_______________________________________

From report at bugs.python.org  Fri May  6 19:31:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:31:58 +0000
Subject: [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1304703118.18.0.963403063153.issue11977@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Also I want to point out that I find the information very hard to
> find as a human. The fact that integers are based on `numbers.Number`
> is -- at this point in time where 95% of all Python developers don't
> know about the `numbers` module or abstract base classes in general
> -- an implementation detail and as such should not affect the way
> `int` is documented.
Not really: int is not based on numbers.Number, but the ABC serves as documentation.

> I propose to have decent class references for int, str, ... similar
> to the reference for dict -- that is, document all attributes and
> methods in one place and make them referencable.
Hum, I think this should be fixed, but not with tons of text containing duplicated information (once for int, once for long, once for float...)  Ezio: you recently fixed a similar problem with collections ABCs methods; what?s your opinion here?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11977>
_______________________________________

From report at bugs.python.org  Fri May  6 19:35:46 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2011 17:35:46 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304703346.27.0.213609870753.issue12014@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Note also that the nested expansion is only allowed in the format_spec part, per the documentation. Your last examples are attempting to do it in the field_name, which leads to the errors you see. Your very last example doesn't look right to me. I'll have to investigate why it's giving you that error message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Fri May  6 19:37:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 May 2011 17:37:41 +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: <1304703461.18.0.44489809637.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

str, list and friends are both functions and classes, if you want to go that way :)  Let?s keep purism out of this and discuss the result: we agree that missing links are a problem, so let?s fix it.

> How could it possibly work
What?s missing is class and method directives.  If you?re interested in submitting a patch, guidelines are found at http://docs.python.org/dev/documenting/markup#information-units and http://docs.python.org/devguide

> without decent documentation about the list data type?
I can understand your feelings, but such a comment is a bit harsh for all the volunteer time that?s been put into documenting Python.  http://docs.python.org/dev/library/functions#list and http://docs.python.org/dev/library/stdtypes#typesseq seem quite ?decent? to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Fri May  6 19:41:56 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2011 17:41:56 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1304703716.87.0.655043667695.issue11072@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Yes, I think this should be committed. I think the API is reasonable, which is the primary concern. If there are implementation bugs, they can be addressed as they're found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Fri May  6 19:44:37 2011
From: report at bugs.python.org (James Hutchison)
Date: Fri, 06 May 2011 17:44:37 +0000
Subject: [issue12020] Attribute error with flush on stdout,stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

When upgrading from Python 3.1 to Python 3.2 I noticed that when my program closed it printed out a non-consequential AttributeError Exception. My program had a custom class that replaced stdout and stderr for use in a piped program (it flushed the buffer after every print statement)

I was able to reduce my code down to this simple test case that will reproduce the issue. Note that this doesn't show up in idle.

code:
import sys
from time import sleep
import subprocess

python31loc = r"C:\python31\python.exe";
python32loc = r"C:\python32\python.exe";
myname = "attributeError.py";

class FlushFile(object):
    #"""Write-only flushing wrapper for file-type objects."""
    def __init__(self, f):
        self.f = f
        try:
            self.encoding = f.encoding;
        except:
            pass;
    def write(self, x):
        self.f.write(x)
        self.f.flush()

# sets stdout and stderr to autoflush
def setAutoFlush():
    if sys.__stdout__ != None: # will be None in IDLE
        sys.stdout = FlushFile(sys.__stdout__);
        sys.stderr = FlushFile(sys.__stderr__);

if __name__ == "__main__":
    setAutoFlush();
    if(len(sys.argv) == 1):
        print("Testing python 3.1");
        output = subprocess.check_output("%s %s -output" % (python31loc, myname));
        print("Should see no error");
        print("Testing python 3.2");
        output = subprocess.check_output("%s %s -output" % (python32loc, myname));
        print("Should see no error");
        sleep(16);


Output:
Testing python 3.1
Should see no error
Testing python 3.2
Exception AttributeError: 'flush' in <__main__.FlushFile object at 0x00C347F0> i
gnored
Should see no error

----------
components: IO, Windows
messages: 135347
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Attribute error with flush on stdout,stderr
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12020>
_______________________________________

From report at bugs.python.org  Fri May  6 19:49:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2011 17:49:22 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <E1QIP9N-0003ip-IV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 56bce38b274f by Giampaolo Rodola' in branch 'default':
Issue #11072: added MLSD command (RFC-3659) support to ftplib.
http://hg.python.org/cpython/rev/56bce38b274f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Fri May  6 19:51:01 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 06 May 2011 17:51:01 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1304704261.63.0.767730843187.issue11072@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee:  -> giampaolo.rodola
components: +Library (Lib)
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Fri May  6 19:52:24 2011
From: report at bugs.python.org (Alex Lai)
Date: Fri, 06 May 2011 17:52:24 +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: <1304704344.46.0.672586367516.issue12013@psf.upfronthosting.co.za>


Alex Lai <alex_lai at scotiacapital.com> added the comment:

Hi Eric,
   Thank you for the reply. I installed Python 3.1.2 pre-compiled by sunfreeware.com on one of our sparc servers.
   Would you please let me know what command I should run to test the installation?

Regard,

Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Fri May  6 19:55:35 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 06 May 2011 17:55:35 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1304704535.88.0.282154733628.issue11072@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Has something prevent you from implementing suggestion provided in my review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Fri May  6 20:11:14 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 06 May 2011 18:11:14 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1304705474.88.0.150179947532.issue11072@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Which ones in particular? msg130474?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Fri May  6 20:12:44 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 May 2011 18:12:44 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304705564.12.0.199639005668.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Victor.  I suspect we're going to need to be a bit more careful, though:  when the extra tests were added for math.log, it turned out that it had all sorts of strange special-case behaviour on various platforms.

So I suspect that even on platforms that have log2 natively, it'll be necessary to factor out special cases and deal with those first, only passing positive finite floats onto the system log2.  Take a look at m_log and the comment directly above it to see how that works.

I'd also like to check in the non-system version first, just to give it a thorough test on the buildbots, before adding in the version that uses the system log2 when available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Fri May  6 20:14:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2011 18:14:22 +0000
Subject: [issue12020] Attribute error with flush on stdout,stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1304705662.6.0.558743339549.issue12020@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  That error message is more than a bit misleading.  What you need to do is add a flush method to your FlushFile class.  Something changed between 3.1 and 3.2 that causes that message to be generated instead of suppressed.  Not sure what it was.  The surprising thing is that you only see it once...flush added to your class is called four times.

There is at least a bug in the message here.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12020>
_______________________________________

From report at bugs.python.org  Fri May  6 20:15:52 2011
From: report at bugs.python.org (Jonas H.)
Date: Fri, 06 May 2011 18:15:52 +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: <1304705752.88.0.247287058559.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Shouldn't have used "decent" here, sorry. What I was trying to say is that there's no "reference-like" documentation for the list datatype (as for dict). There's more than enough quality documentation about lists but I think the way it's arranged can be improved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Fri May  6 20:21:24 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 06 May 2011 18:21:24 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304706084.37.0.955924053776.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

My last examples were actually just attempting to figure out what triggered the unexpected behavior. I don't want to do expansion inside the field_name part!

(I'll have a reply to your previous comment about use-cases shortly.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Fri May  6 20:24:43 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 06 May 2011 18:24:43 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1304706283.2.0.605648070807.issue11072@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

a review on rietveld http://bugs.python.org/review/11072/show
which as I confirmed with you specifically at #python-dev you received a notification of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Fri May  6 20:28:06 2011
From: report at bugs.python.org (James Hutchison)
Date: Fri, 06 May 2011 18:28:06 +0000
Subject: [issue12020] Attribute error with flush on stdout,stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1304706486.54.0.452592592595.issue12020@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

You are right, when I add:

    def flush(self):
        pass;

the error goes away.

When I have this:

    def flush():
        pass;

I get:

Exception TypeError: 'flush() takes no arguments (1 given)' in <__main__.FlushFile object at 0x00C2AB70> ignored

This leads me to believe that sys.stdout.flush() is being called on program close

So this would be the correct implementation of my flushfile override:

class FlushFile(object):
    #"""Write-only flushing wrapper for file-type objects."""
    def __init__(self, f):
        self.f = f;
        self.flush = f.flush;
        try:
            self.encoding = f.encoding;
        except:
            pass;
    def write(self, x):
        self.f.write(x)
        self.f.flush()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12020>
_______________________________________

From report at bugs.python.org  Fri May  6 20:48:07 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 06 May 2011 18:48:07 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <1304707687.84.0.159516911087.issue11072@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

In my view, aside from the documentation note they're all minor/styling-related changes but feel free to provide a patch if you want to and I'll commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Fri May  6 20:57:51 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2011 18:57:51 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304708271.66.0.340131664836.issue12017@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for the patch.  I'll apply this to 2.6svn for the 2.6.7rc1 release today.  Feel free to apply this to 2.6hg and forward port it to the relevant releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12017>
_______________________________________

From report at bugs.python.org  Fri May  6 21:12:49 2011
From: report at bugs.python.org (David Coles)
Date: Fri, 06 May 2011 19:12:49 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1304709169.2.0.592458854747.issue12010@psf.upfronthosting.co.za>


David Coles <coles.david at gmail.com> added the comment:

After doing some more investigation it appears that Android's wchar_t support before android-9 is totally broken (see http://android.git.kernel.org/?p=platform/ndk.git;a=blob_plain;f=docs/STANDALONE-TOOLCHAIN.html;hb=HEAD). With android-9 you get 4 byte wchar_t and working wide character functions.

Possibly of more interest for Python is that it's no longer buildable without wchar_t support. While unicodeobject is pretty good at checking HAVE_WCHAR_H, a number of modules and even pythonrun.c directly use wchar_t or functions like PyUnicode_FromWideChar without providing a fallback. Does Python 3 now require wchar_t or are these bugs? (either option seems sensible).

A few other notes:
HAVE_USABLE_WCHAR_T looks like it was a check for unsigned/>16 bits wchar_t that would allow them to be directly memcpy'd. The code in unicodeobject.c seems not to really use this anymore except (it's happy with signed or unsigned) and it looks like the check is only used for Windows now.

To properly support wchar_t of size 1 you would basically implement multibyte character storage either with UTF-8 or just packing two wchar_t's with UTF-16. At least in Android the distinction doesn't seem to matter as Android's internationalziation/localization policy seems to be "use Java".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri May  6 21:41:27 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2011 19:41:27 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304710887.59.0.495708776089.issue12017@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Not applicable to 2.6 after all.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12017>
_______________________________________

From report at bugs.python.org  Fri May  6 21:54:14 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Fri, 06 May 2011 19:54:14 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>


New submission from K Richard Pixley <rich at noir.com>:

mmap.read requires a argument.  Since most file-like objects do not, this breaks the file-like object illusion.

mmap.read argument should be optional, presumably defaulting to the entire mmap'd area.

----------
messages: 135362
nosy: rich-noir
priority: normal
severity: normal
status: open
title: mmap.read requires an argument
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/issue12021>
_______________________________________

From report at bugs.python.org  Fri May  6 21:55:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 19:55:46 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304709169.2.0.592458854747.issue12010@psf.upfronthosting.co.za>
Message-ID: <1304711736.3520.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Possibly of more interest for Python is that it's no longer buildable
> without wchar_t support. While unicodeobject is pretty good at
> checking HAVE_WCHAR_H, a number of modules and even pythonrun.c
> directly use wchar_t or functions like PyUnicode_FromWideChar without
> providing a fallback. Does Python 3 now require wchar_t or are these
> bugs? (either option seems sensible).

It's pretty much required since we rely on mbstowcs and friends to
convert some 8-bit strings (such as environment variables, command-line
args...) to unicode.

> At least in Android the distinction doesn't seem to matter as
> Android's internationalziation/localization policy seems to be "use
> Java".

Ha :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri May  6 21:56:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2011 19:56:52 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1304711812.05.0.9890851362.issue12021@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sounds like a reasonable request, although I don't think it's a bug fix in itself (there are probably other places where mmap breaks the file-like expectation).

----------
nosy: +pitrou
stage:  -> needs patch
type: behavior -> 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/issue12021>
_______________________________________

From report at bugs.python.org  Fri May  6 22:07:23 2011
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 06 May 2011 20:07:23 +0000
Subject: [issue12022] 'transaction' module-as-context-manager thwarted by
	Python 2.7.1
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>


New submission from Daniel Holth <dholth at fastmail.fm>:

"How much do we care about special method lookup?" Python recently bypasses __getattr__ entirely when looking up context managers. http://mail.python.org/pipermail/python-dev/2009-May/089535.html

Could this be the reason that ZODB's transaction module, which attempts to be a context manager by declaring

manager = ThreadTransactionManager()
__enter__ = manager.get
__exit__ = manager.__exit__

Does not work in Python 2.7.1 on Ubuntu 11.04 or RHEL5? Frustratingly, the exception is no more specific than an AttributeError, even though hasattr(transaction, '__exit__')?

I would prefer to never get AttributeError: transaction.__exit__ when hasattr(transaction, '__exit__') as I find that to be very confusing. Maybe the interpreter could raise SpecialAttributeError('transaction.__exit__ is not sufficiently special') instead.

http://svn.zope.org/repos/main/transaction/trunk/transaction/__init__.py

----------
components: Interpreter Core
messages: 135365
nosy: dholth
priority: normal
severity: normal
status: open
title: 'transaction' module-as-context-manager thwarted by Python 2.7.1
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12022>
_______________________________________

From report at bugs.python.org  Fri May  6 22:13:34 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 06 May 2011 20:13:34 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1304712814.2.0.617186754162.issue12021@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/issue12021>
_______________________________________

From report at bugs.python.org  Fri May  6 22:31:05 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 06 May 2011 20:31:05 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304709169.2.0.592458854747.issue12010@psf.upfronthosting.co.za>
Message-ID: <4DC45A81.3000101@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

David Coles wrote:
> 
> David Coles <coles.david at gmail.com> added the comment:
> 
> After doing some more investigation it appears that Android's wchar_t support before android-9 is totally broken (see http://android.git.kernel.org/?p=platform/ndk.git;a=blob_plain;f=docs/STANDALONE-TOOLCHAIN.html;hb=HEAD). With android-9 you get 4 byte wchar_t and working wide character functions.
>
> Possibly of more interest for Python is that it's no longer buildable without wchar_t support. While unicodeobject is pretty good at checking HAVE_WCHAR_H, a number of modules and even pythonrun.c directly use wchar_t or functions like PyUnicode_FromWideChar without providing a fallback. Does Python 3 now require wchar_t or are these bugs? (either option seems sensible).

wchar_t should be fairly portable these days. I think the main
problem is that we never assumed sizeof(wchar_t) == 1 to be a
possibility. On Windows, wchar_t was 16 bit and the glibc started
out with 32 bits.

> A few other notes:
> HAVE_USABLE_WCHAR_T looks like it was a check for unsigned/>16 bits wchar_t that would allow them to be directly memcpy'd. The code in unicodeobject.c seems not to really use this anymore except (it's happy with signed or unsigned) and it looks like the check is only used for Windows now.

Note that HAVE_USABLE_WCHAR_T is only used to check whether
Python can use wchar_t as alias for Py_UNICODE. Python's Unicode
implementation needs Py_UNICODE to be an unsigned type with
either 2 bytes or 4 bytes. If wchar_t does not provide these
sizes or is a signed type, Python cannot use it for Py_UNICODE
and must instead use "unsigned short".

If the configure script does not detect this case, then a patch
would be helpful.

The other wchar_t C lib functions should still remain usable,
though.

> To properly support wchar_t of size 1 you would basically implement multibyte character storage either with UTF-8 or just packing two wchar_t's with UTF-16. At least in Android the distinction doesn't seem to matter as Android's internationalziation/localization policy seems to be "use Java".

Python should not use wchar_t for Py_UNICODE on such platforms
and instead go with "unsigned short".

I would assume that the wchar_t C lib routines work based on UTF-8
with sizeof(wchar_t) == 1, so the PyUnicode_*WideChar*() APIs would
need to be adjusted to work more or less like the UTF-8 codecs.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri May  6 22:37:46 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 06 May 2011 20:37:46 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <4DC45A81.3000101@egenix.com>
Message-ID: <4DC45C15.2060905@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

>From the document you posted:

"""
As documented, the Android platform did not really support wchar_t until
Android 2.3. What this means in practical terms is that:

  - If you target platform android-9 or higher, the size of wchar_t is
    4 bytes, and most wide-char functions are available in the C library
    (with the exception of multi-byte encoding/decoding functions and
     wsprintf/wsscanf).

  - If you target any prior API level, the size of wchar_t will be 1 byte
    and none of the wide-char functions will work anyway.

We recommend any developer to get rid of any dependencies on the wchar_t type
and switch to better representations. The support provided in Android is only
there to help you migrate existing code.
"""

With none of the wide-char functions working in Android <2.3, I don't
think you have a good chance of getting Python 3.x working, unless
you remove all their uses in the code and replace them with standard
char* functions.

The last paragraph doesn't sound very promising either. I wonder
what they mean with "better representation". The C standard doesn't
have any better representation for Unicode at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri May  6 22:40:16 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 06 May 2011 20:40:16 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1304714416.55.0.30233037943.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

Here's my use case.

I'm writing a python version of the ruby library HighLine for CLI interaction, to be called, uncreatively, PyLine. One of the moderately neat things about the library is that it allows for color information to be embedded in the strings one passes to its methods, so, if h is a HighLine object, you could say:

h.say "<%= color('this will be red', :red) %> but this won't be"

So I wanted to be able to provide some kind of similar facility and realized that the __getitem__ method supported by format(), along with some __getattribute__ trickery, would work: so if p is a PyLine object, you could say:

p.say("{colors.red.bold.on_black[this will be bold with red text on a black background]} but this will be just be regular text")

Thus:

>>> effectize_string("{colors.red.bold.on_black[this will be bold with red text on a black background]} but this will just be regular text")
'\x1b[31m\x1b[1m\x1b[40mthis will be bold with red text on a black background\x1b[0m but this will just be regular text\x1b[0m'

Obviously, I'll already have to watch out for stray "]"s in the string passed to the object's __getitem__, so you might think, well, it's not much more work to also have to watch out for stray ":", "!", "}", and "{" (but, oddly I won't need to watch out for *match* "{" and "}"!).

But it's obvious that something here should change. For one thing, as it stands, the documentation is wrong; it is not the case that an index_string can contain any character except ']'. But the documentation describes the way things rationally ought to be; there's a good reason not to allow a ']' in the index_string (and one can see why simplicity suggests not allowing for *escapes*, though I think that ideally there would be an escaping mechanism). But there's no reason not to allow stray "{", "}", ":", and "!" in the index_string. The only reason it's true at this point that "it doesn't know they're in an index field when it's doing the parsing for ':' or '!'" is that (assuming one takes the grammar in the documentation to be accurate) the parser is written incorrectly.

It contains, for instance, incorrect comments (in string_format.h:parse_field):
<code>
    /* Search for the field name.  it's terminated by the end of
       the string, or a ':' or '!' */
    field_name->ptr = str->ptr;
    while (str->ptr < str->end) {
        switch (c = *(str->ptr++)) {
        case ':':
        case '!':
            break;
        default:
            continue;
        }
        break;
    }
</code>

(hopefully &lt;code&gt; does the right thing here...)

That's the culprit for the mishandling of ":" and "!", but it is simply not the case---again, according to the grammar given in the documentation---that the field name can be delimited this way, in two ways.*

And, given that no nested expansion is done in the field_name part of the replacement, there's no real reason to retain the present parsing strategy; none of !, :, {, or } has any semantic significance in this part of of the replacement string, so why should the parsing code treat them specially? Surely, even if you think my use case is not so great, there's value in doing it right.

The ":" and "!" problem is not super hard to get around. Witness the following dirty hack:

<code>
void 
advance_beyond_field(SubString *str)
{
    if (str->ptr > str->end) return;
    switch (*++str->ptr) {
    case '[':
        while(str->ptr < str->end && *(str->ptr) != ']') 
            str->ptr++;
        advance_beyond_field(str);
        break;
    case '.':
        while(str->ptr < str->end)
            switch(*++str->ptr) {
            case ':':
            case '!':
                str->ptr--;
                return;
            case '[':
                advance_beyond_field(str);
                str->ptr--;
                break;
            default:
                continue;
            }
        break;
    default:
        return;
    }       
}
</code>
Followed by replacing the switch statement as above thus:
<code>
        switch (c = *(str->ptr++)) {
        case '.':
        case '[':
            str->ptr -= 2;
            advance_beyond_field(str);
            continue;
        case ':':
        case '!':
            break;
        default:
            continue;
        }
</code>
Of course, there is already in the FieldNameIterator plumbing a more certain mechanism for actually getting the fields out.

Then one can do this:

>>> "{0[:]}".format({":":4})
'4'
>>> "{0[{ : ! }]}".format({"{ : ! }":4})
'4'

(One can also pass such formatting-exercising test suites as test_nntplib, test_string, and test_collections.)

Though still not this:

>>> "{0[{]}".format({"{":4})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format

Even though the stray "{" in the square brackets has no semantic significance, it still gets picked up; the culprit is apparently in MarkupIterator_next, whose initial bracket-detecting while loop is not square-bracket aware. One couldn't just add a "case '[':" to its switch statement because '[' could be a fill character, but since a fill character can only occur after a ':', and a field_name *can't* occur after a ':' or a '!' a flag for whether a '[' is significant could presumably get around that. Something like (not even remotely tested):
<code>
        case '[':
            if (bracket_significant)
                while(self->str.ptr < self->str.end && *self->str.ptr != ']') {
                    self->str.ptr++;
                }
            continue;
        case ':':
        case '!':
            bracket_significant = 0;
</code>
bracket_significant having been initialized to 1.

If something like the above works, then it seems to me that it would take a very small benefit to outweigh the effort necessary to do this right.

* the second way I don't really care about: the grammar identifies an "attribute_name" as an identifier, but in fact any string will work and will be passed to getattr: 
>>> "{0.4}".format(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object has no attribute '4'
>>> "{0.-}".format(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object has no attribute '-'
Neither "4" nor "-" is a valid Python identifier, so the actual parsing code disagrees with the documented grammar here as well. Here I think it would be better just to change the documented grammar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Fri May  6 23:24:55 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 06 May 2011 21:24:55 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1304717095.82.0.106731542637.issue12010@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think what they mean is a better representation from an Android API, such as UChar32 from utils/AndroidUnicode.h.

I agree that it's not worthwhile trying to port Python to those Android versions that have a single-byte wchar_t definition. 

David, I think you are misunderstanding the purpose of HAVE_USABLE_WCHAR_T: It does *not* specify whether wchar_t can be used. Instead, it specifies whether wchar_t can be used as the datatype for Py_UNICODE. Calling it HAVE_A_WCHAR_T_DEFINITION_THAT_IS_SUITABLE_FOR_USE_AS_BASE_TYPE_OF_PY_UNICODE was just a little too tedious :-)

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri May  6 23:34:52 2011
From: report at bugs.python.org (David Coles)
Date: Fri, 06 May 2011 21:34:52 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <4DC45C15.2060905@egenix.com>
Message-ID: <BANLkTikAcwmm70QiG-2JSLXVoGXgVb+_1A@mail.gmail.com>


David Coles <coles.david at gmail.com> added the comment:

On Fri, May 6, 2011 at 1:31 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> wchar_t should be fairly portable these days. I think the main
> problem is that we never assumed sizeof(wchar_t) == 1 to be a
> possibility. On Windows, wchar_t was 16 bit and the glibc started
> out with 32 bits.

Well a 1 byte wchar_t is a bit "ass backwards". I think it's very much
an edge case. :)

> Note that HAVE_USABLE_WCHAR_T is only used to check whether
> Python can use wchar_t as alias for Py_UNICODE. Python's Unicode
> implementation needs Py_UNICODE to be an unsigned type with
> either 2 bytes or 4 bytes. If wchar_t does not provide these
> sizes or is a signed type, Python cannot use it for Py_UNICODE
> and must instead use "unsigned short".

Right. That makes sense. In that case it's probably sensible to keep around.

> If the configure script does not detect this case, then a patch
> would be helpful.

Yup. I'll put something together that causes configure to bail out if
you're either missing HAVE_WCHAR_H or if SIZEOF_WCHAR_T is less than
16 bits.

> Python should not use wchar_t for Py_UNICODE on such platforms
> and instead go with "unsigned short".
>
> I would assume that the wchar_t C lib routines work based on UTF-8
> with sizeof(wchar_t) == 1, so the PyUnicode_*WideChar*() APIs would
> need to be adjusted to work more or less like the UTF-8 codecs.

Yes. Using UTF-8 would be the sensible solution. Sadly it looks like
all the wide character functions <2.3 are undefined, so in this case
Android saying it has wchar_t support is worse than useless.

On Fri, May 6, 2011 at 1:37 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> With none of the wide-char functions working in Android <2.3, I don't
> think you have a good chance of getting Python 3.x working, unless
> you remove all their uses in the code and replace them with standard
> char* functions.

I agree. In my case I should be able to bump the required version
number without too much fuss. It seems a bit silly to write in support
for a platform that no longer supports said feature.

> The last paragraph doesn't sound very promising either. I wonder
> what they mean with "better representation". The C standard doesn't
> have any better representation for Unicode at the moment.

In C I guess the only sensible alternative would be UTF-8 char strings
(or maybe using uint32_t), but in Python's case it really depends on
how the underlying OS represents internationalized characters. Perhaps
in other projects you would use an external library like ICU, but
that's out the scope of my experience. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri May  6 23:41:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2011 21:41:22 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1304718082.03.0.0912503254358.issue11957@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I like the idea of an internal REflag class with __new__, __or__, and __repr__==__str__. Str(re.A|re.L) might print as
"REflag: re.ASCII | re.IGNORE"
If it is *not* an int subclass, any attempt to use or mix with an int would raise. I checked and the doc only promises that flags can be or'ed. An __and__ method might be added if it were thought that people currently use & to check for flags set, though that is not currently promised.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Fri May  6 23:42:11 2011
From: report at bugs.python.org (David Coles)
Date: Fri, 06 May 2011 21:42:11 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304717095.82.0.106731542637.issue12010@psf.upfronthosting.co.za>
Message-ID: <BANLkTin_etyvNB1ZQOAzAF-3_W2rtqEv8Q@mail.gmail.com>


David Coles <coles.david at gmail.com> added the comment:

On Fri, May 6, 2011 at 2:24 PM, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> I think what they mean is a better representation from an Android API, such as UChar32 from utils/AndroidUnicode.h.

Ah. Sadly I don't think that's exposed in the NDK yet.

> I agree that it's not worthwhile trying to port Python to those Android versions that have a single-byte wchar_t definition.

Yup. Will be using Android 2.3+. If I'm forced to use an earlier
version of Android I think it would be more sensible to use the 2.x
series of Python.

> David, I think you are misunderstanding the purpose of HAVE_USABLE_WCHAR_T: It does *not* specify whether wchar_t can be used. Instead, it specifies whether wchar_t can be used as the datatype for Py_UNICODE. Calling it HAVE_A_WCHAR_T_DEFINITION_THAT_IS_SUITABLE_FOR_USE_AS_BASE_TYPE_OF_PY_UNICODE was just a little too tedious :-)

Haha :). Yes. My initial reading of the pyconfig.h was wrong. Got a
bit suspicious when my Linux box was not defining it. Then I saw them
memcpy and it made sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri May  6 23:57:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2011 21:57:53 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304719073.75.0.336904824555.issue11959@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I looked as the small patch to smptd.py. This strikes me a a reasonable use of dependency injection to make smptd more usable in testing, especially given that asyncx are have it.

The only thing I do not understand fully is the redefinition of set_socket, perhaps because I do not know where the original is that is being replaced.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Sat May  7 00:15:09 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 06 May 2011 22:15:09 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304720109.1.0.654940744327.issue10419@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Please commit any patch before releases of Python 3.1.4 and 3.2.1. (3.2.1 rc1 is planned on 2011-05-14.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Sat May  7 00:17:14 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 06 May 2011 22:17:14 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <BANLkTin_etyvNB1ZQOAzAF-3_W2rtqEv8Q@mail.gmail.com>
Message-ID: <4DC47365.8060802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

David Coles wrote:
> 
>> I agree that it's not worthwhile trying to port Python to those Android versions that have a single-byte wchar_t definition.
> 
> Yup. Will be using Android 2.3+. If I'm forced to use an earlier
> version of Android I think it would be more sensible to use the 2.x
> series of Python.

Since you sound like you want to get Python running on Android,
are you aware of this project ?

  http://code.google.com/p/android-scripting/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Sat May  7 00:40:29 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 06 May 2011 22:40:29 +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: <1304721629.88.0.0214628335849.issue11277@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Thanks for the tests; I'll review and commit them tomorrow morning.

> Even if that means that there is no test which checksums an
> entire superlarge mmap() region.

Bear in mind that the test is only to be removed from 2.7; it will still
be present in the 3.* branches, where crc32() and adler32() actually can
accept such large inputs.

@haypo, @pitrou: Are there any objections to removing test_big_buffer()
from Lib/test/test_zlib.py? If not, I think we can close this issue once
that and the additional mmap tests are committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 00:40:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2011 22:40:58 +0000
Subject: [issue11963] Use real assert* for test_trigger_memory_error
	(test_parser)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1304721658.48.0.17917441863.issue11963@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Unlike test.support, whose doc was recently expanded by a patch by Eli Bendersky, I see no mention of test.script helper in the test doc. [Do you think there should be?]. I was not aware of it. It might be newer than the 'old way'.

I would have titled this 'Removed human verification from test suite'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11963>
_______________________________________

From report at bugs.python.org  Sat May  7 00:47:41 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 06 May 2011 22:47:41 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304722061.35.0.710169649295.issue11959@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's create_socket which is being redefined, because the base class implementation

https://bitbucket.org/mirror/cpython/src/5661480f7763/Lib/asyncore.py#cl-292

calls set_socket without passing a map.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Sat May  7 00:49:58 2011
From: report at bugs.python.org (David Coles)
Date: Fri, 06 May 2011 22:49:58 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <4DC47365.8060802@egenix.com>
Message-ID: <BANLkTimW-p5qPxY+3urSpX2ZROVxVYkFnQ@mail.gmail.com>


David Coles <coles.david at gmail.com> added the comment:

On Fri, May 6, 2011 at 3:17 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
> Since you sound like you want to get Python running on Android,
> are you aware of this project ?
>
> ?http://code.google.com/p/android-scripting/

Yes. It's excellent. I've actually been using it as a porting
reference for Python 3.

The problem is work decided to be very future proof with it's clients
and decided to use Python 3 as the embedded scripting language.
Because of differences in the C API, it looked like it might be easier
to do a port of Python 3 to Android (we already cross compile an ARM
version for another Linux platform) then to have the Android client
with 2.6 version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Sat May  7 00:53:05 2011
From: report at bugs.python.org (Rodrigo Ventura)
Date: Fri, 06 May 2011 22:53:05 +0000
Subject: [issue12023] non causal behavior
In-Reply-To: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>
Message-ID: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>


New submission from Rodrigo Ventura <rodrigo.ventura.isr at gmail.com>:

Consider these two functions:
---
def nok():
    a = None
    def f():
        if a:
            a = 1
    f()

def ok():
    a = None
    def f():
        if a:
            b = 1
    f()
---

Function ok() executes fine, but function nok() trigger an exception:

Traceback (most recent call last):
  File "pb.py", line 20, in <module>
    nok()
  File "pb.py", line 7, in nok
    f()
  File "pb.py", line 5, in f
    if a:
UnboundLocalError: local variable 'a' referenced before assignment

There is no reason for this to happen

Regards,
Rodrigo Ventura

----------
messages: 135380
nosy: Rodrigo.Ventura
priority: normal
severity: normal
status: open
title: non causal behavior
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12023>
_______________________________________

From report at bugs.python.org  Sat May  7 00:57:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 22:57:15 +0000
Subject: [issue12023] non causal behavior
In-Reply-To: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>
Message-ID: <1304722635.56.0.418561755237.issue12023@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The reason is that in nok Python sees the assignment to a (a = 1) and determines that the 'a' variable is local to the scope of f, and since the assignment comes after the "if a:" and at that point 'a' has no value, an error is raised.
In ok there's no assignment to 'a', so Python assume that 'a' refers to the 'a' variable defined in the outer scope.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12023>
_______________________________________

From report at bugs.python.org  Sat May  7 00:58:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 22:58:36 +0000
Subject: [issue12023] non causal behavior
In-Reply-To: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>
Message-ID: <1304722716.17.0.945719844962.issue12023@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also http://docs.python.org/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12023>
_______________________________________

From report at bugs.python.org  Sat May  7 01:20:15 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2011 23:20:15 +0000
Subject: [issue12024] 2.6 svn and hg branches are out of sync
In-Reply-To: <1304724015.49.0.713905819899.issue12024@psf.upfronthosting.co.za>
Message-ID: <1304724015.49.0.713905819899.issue12024@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Martin points out that the svn and hg branches for 2.6 are out of sync.  I made the 2.6.7rc1 release from svn, without sync'ing them up.  I have no time to do the sync right now, so for 2.6.7 final (or 2.6.7rc2?) the branches must be synchronized.

Possibly related: decide whether to actually do the final release from hg or svn.

----------
assignee: barry
messages: 135383
nosy: barry
priority: release blocker
severity: normal
status: open
title: 2.6 svn and hg branches are out of sync
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12024>
_______________________________________

From report at bugs.python.org  Sat May  7 01:20:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 06 May 2011 23:20:31 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304724031.17.0.367775933133.issue11948@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here's attached the patch including Terry's suggestion (gaah, sorry for this late reply).

----------
Added file: http://bugs.python.org/file21913/issue11948-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Sat May  7 01:31:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 May 2011 23:31:55 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304724715.54.0.529113880458.issue11948@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

s/``sys.path``/:data:`sys.path`/ (or whatever turns that into a link).
I also don't like the "Python programs that know what they're doing" bit.
The list of places where the modules are searched could be a bullet list.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Sat May  7 01:32:44 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 06 May 2011 23:32:44 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1304724764.87.0.975468189004.issue11957@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Something like "<re.Flag ASCII | IGNORE>" may be more Pythonic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Sat May  7 01:46:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2011 23:46:57 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <1304725617.42.0.379435145255.issue11968@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Takayuki is correct, the status and header strings should, it seems, be 'native strings', not bytes.

The experimental proof is to run the current example code (I did so from IDLE editor window on WinXP) and then enter http://localhost:8000/
in a browser. Several error messages appear back in the shell window, like
AssertionError: Header names/values must be of type str (got b'Content-type')
Hit ^C to stop. Delete the b prefixes from the code. Rerun. Reaccess.
And the environment dict appears as promised:
TMP: C:\DOCUME~1\Terry\LOCALS~1\Temp
WATCOM: C:\temp\WatconPermanent
COMPUTERNAME: HP-PAVILION
wsgi.multiprocess: False
...
Takayuki, if you did the same thing, it would have been helpful if you had said so.

Neither version works in 3.1.3. No exception messages either. Firefox says unable to connect. I retried with 3.2.0 and patched example and it worked again.

Running this down in the docs was harder. In the example, function simple_app is a WSGI application object. The status and header objects are passed to the start_response function passed to simple_app after simple_app is passed to make_server. The manual (elsewhere) refers to PEP 3333 for the definition of WSGI app object. The 'start_response Callable' section says the status passed to start_response should be a string and that headers should be a list of tuples of header key and value, but it does not specify the type of the latter. The earlier 'Note on String Types says that headers are, for convenience, native-to-the-version strings while bodies are bytes. So the revised example that works matches the doc.

Phillip or David, can you verify that this is all as intended?

----------
nosy: +pje, r.david.murray, terry.reedy
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11968>
_______________________________________

From report at bugs.python.org  Sat May  7 01:50:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 May 2011 23:50:50 +0000
Subject: [issue12022] 'transaction' module-as-context-manager thwarted by
	Python 2.7.1
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1304725850.62.0.365412046664.issue12022@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, that's why. I suggest you appeal to python-ideas about the new exception.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12022>
_______________________________________

From report at bugs.python.org  Sat May  7 02:03:24 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 07 May 2011 00:03:24 +0000
Subject: [issue6116] frame.f_locals keeps references to things for too long
In-Reply-To: <1243351626.66.0.213520935039.issue6116@psf.upfronthosting.co.za>
Message-ID: <1304726604.14.0.372209412564.issue6116@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I tried making f_locals always a copy but it wreaks havoc with some code which expects changing it to "work", namely pdb. I resign myself to using weakrefs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6116>
_______________________________________

From report at bugs.python.org  Sat May  7 02:11:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 00:11:30 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1304727090.8.0.161138251041.issue11959@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

OK, passing self.sockmap=None to setsocket matches its current behavior, so your new code should not change any current smtpd users, while modifying asyncore.dispatcher.create_socket might possibly affect someone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Sat May  7 02:13:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 00:13:28 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1304727208.92.0.137323000706.issue11957@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Agreed, if we go that route.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Sat May  7 02:33:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 00:33:17 +0000
Subject: [issue11969] Can't launch Process on built-in static method
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1304728397.7.0.00371016947368.issue11969@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Running on winxp with IDLE, I get the second traceback, all the same after the first line. Given "target is the callable object to be invoked by the run() method.", I would have expected this to work too.

Problem is not builtins:
class C:
    def f(s): print( 'here')

p = multiprocessing.Process(target=C.f, args=(C(),))
p.start()

gives same error, ending in
_pickle.PicklingError: Can't pickle <function f at 0x00FE5AE0>: it's not found as __main__.f

----------
nosy: +jnoller, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Sat May  7 02:33:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 00:33:55 +0000
Subject: [issue11972] input does not strip a trailing newline correctly on
	Windows
In-Reply-To: <1304261913.63.0.142734061698.issue11972@psf.upfronthosting.co.za>
Message-ID: <1304728435.17.0.83129191768.issue11972@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11972>
_______________________________________

From report at bugs.python.org  Sat May  7 02:36:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 00:36:08 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1304728568.4.0.477116277706.issue11969@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
title: Can't launch Process on built-in static method -> Can't launch multiproccessing.Process on methods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Sat May  7 02:39:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 00:39:44 +0000
Subject: [issue11668] _multiprocessing.Connection.poll with timeout uses
	polling under Windows
In-Reply-To: <1301012856.06.0.501822966935.issue11668@psf.upfronthosting.co.za>
Message-ID: <1304728784.42.0.985321241331.issue11668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This doesn't seem to be so easy. WFMO (or WFSO) often seems to return successfully while there's no message to read on the pipe end. Here is a sample session (disturbing results):

>>> a, b = connection.Pipe(True)
>>> win32.WaitForMultipleObjects([a._handle], True, 1000)
258
>>> win32.WaitForMultipleObjects([b._handle], True, 1000)
0
>>> win32.PeekNamedPipe(a._handle)
(0, 0)
>>> win32.WaitForMultipleObjects([a._handle], True, 1000)
0

(do note how the end created with CreateFile() is considered ready by WaitForMultipleObjects, while the end created with CreateNamedPipe() is considered ready after an unsuccessful call to PeekNamedPipe()!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11668>
_______________________________________

From report at bugs.python.org  Sat May  7 03:01:59 2011
From: report at bugs.python.org (John S. Gruber)
Date: Sat, 07 May 2011 01:01:59 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat[ST_MTIME]
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1304730119.17.0.634250004967.issue11933@psf.upfronthosting.co.za>


John S. Gruber <johnsgruber at gmail.com> added the comment:

As ?ric suggested I opened issue 11993 a couple of days ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11933>
_______________________________________

From report at bugs.python.org  Sat May  7 03:07:19 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sat, 07 May 2011 01:07:19 +0000
Subject: [issue11983] Inconsistent hash and comparison for code objects
In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za>
Message-ID: <1304730439.73.0.856687605345.issue11983@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

I would propose changing implementation to match the comment. At a minimum, remove co_firstlineno comparison. As the last resort, at least change the comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11983>
_______________________________________

From report at bugs.python.org  Sat May  7 03:20:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 01:20:40 +0000
Subject: [issue11980] zipfile.ZipFile.write should accept fp as argument
In-Reply-To: <1304354092.27.0.477434523561.issue11980@psf.upfronthosting.co.za>
Message-ID: <1304731240.92.0.112266737226.issue11980@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

zipfile.ZipFile takes a file arg that can be a 'path to a file (a string) or a file-like object'. The .write() method takes a filename arg. I would think that the proposal should be what the title says, to expand that to a file arg, either a path or 'file', as with ZipFile itself. I cannot think of any reason not to do that.

The patch adds a separate .writefp method with the file and arcname switched and the compression_type omitted. The code is mostly a duplicated subset of .write. While is proves the concept, none of the differences strike me as good. I think instead there should just be one method that branches, where appropriate, on the type of 'file', just as ZipFile.__init__ does. I admit that I do not understand what .write is supposed to do or does do when filename is a directory.

The patch includes a test. It still needs doc and News patches, but those come after the basic patch is done.

----------
nosy: +alanmcintyre, terry.reedy
stage:  -> patch review
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11980>
_______________________________________

From report at bugs.python.org  Sat May  7 03:30:41 2011
From: report at bugs.python.org (James Tatum)
Date: Sat, 07 May 2011 01:30:41 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1304731841.59.0.125377287275.issue11623@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


----------
nosy: +James.Tatum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sat May  7 03:33:22 2011
From: report at bugs.python.org (David Kern)
Date: Sat, 07 May 2011 01:33:22 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1304732002.05.0.207074846642.issue1006238@psf.upfronthosting.co.za>


Changes by David Kern <ipsuid at gmail.com>:


----------
nosy: +David.Kern

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Sat May  7 03:34:17 2011
From: report at bugs.python.org (David Kern)
Date: Sat, 07 May 2011 01:34:17 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1304732057.34.0.183812244152.issue3754@psf.upfronthosting.co.za>


Changes by David Kern <ipsuid at gmail.com>:


----------
nosy: +David.Kern

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Sat May  7 04:22:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 07 May 2011 02:22:57 +0000
Subject: [issue12025] strangely missing separator in "resource" table
In-Reply-To: <1304734977.84.0.0748743077356.issue12025@psf.upfronthosting.co.za>
Message-ID: <1304734977.84.0.0748743077356.issue12025@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

"resource" page in python docs is missing a separator between 6 and 7. Checking the RST source code, everything seems correct. But the fact is that a line is missing in the HTML output.

Checking the HTML output code, it seems OK. Disabling CSS, I see the table is correct. Maybe an issue with the CSS?. A bug in Firefox 4.0.1? (my current browser).

Viewing in iPhone, the display is OK :-?.

Python 2.7:
http://docs.python.org/library/resource.html#resource-usage

Python 3.1:
http://docs.python.org/release/3.1.3/library/resource.html#resource-usage

Python 3.2:
http://docs.python.org/py3k/library/resource.html#resource-usage

Python 3.3:
http://docs.python.org/dev/library/resource.html#resource-usage

----------
assignee: docs at python
components: Documentation
messages: 135397
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: strangely missing separator in "resource" table
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12025>
_______________________________________

From report at bugs.python.org  Sat May  7 04:27:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 02:27:24 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <E1QIXEo-0006Ir-Po@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a0147a1f1776 by R David Murray in branch '2.7':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/a0147a1f1776

New changeset 252451fef13f by R David Murray in branch '3.1':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/252451fef13f

New changeset 6907c43d1ee7 by R David Murray in branch '3.2':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/6907c43d1ee7

New changeset 214a34b26e1b by R David Murray in branch 'default':
#11999: sync based on comparing mtimes, not mtime to system clock
http://hg.python.org/cpython/rev/214a34b26e1b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________

From report at bugs.python.org  Sat May  7 04:28:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 May 2011 02:28:59 +0000
Subject: [issue11999] sporadic failure in test_mailbox
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304735339.26.0.437366514309.issue11999@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Now we see if the buildbots agree with me that this is fixed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
title: sporadic failure in test_mailbox on FreeBSD -> sporadic failure in test_mailbox
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________

From report at bugs.python.org  Sat May  7 05:21:35 2011
From: report at bugs.python.org (Rodrigo Ventura)
Date: Sat, 07 May 2011 03:21:35 +0000
Subject: [issue12023] non causal behavior
In-Reply-To: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>
Message-ID: <1304738495.58.0.121830712707.issue12023@psf.upfronthosting.co.za>


Rodrigo Ventura <rodrigo.ventura.isr at gmail.com> added the comment:

Ezio,

thank you for the explanation.

Is it possible to access variable a in nok's scope from function f without using the global keyword in f? (so that variable a remains local to nok, rather than global to python)

Rodrigo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12023>
_______________________________________

From report at bugs.python.org  Sat May  7 06:50:25 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 07 May 2011 04:50:25 +0000
Subject: [issue12026] Support more of MSI api by exposing handles
In-Reply-To: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>
Message-ID: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>


New submission from Mark Mc Mahon <mtnbikingmark at gmail.com>:

Background:
My main use case for msilib is for working with/editing existing MSI files and not creating MSI files.

As such I find much of the MSI API that I need missing.

While not difficult to re-create _msi.c with ctypes, I thought it might be good to use as much of _msi.c as implemented (faster :) )

Patch:
The patch exposes the 'h' member of msiobj as 'handle', and updates the doc to refer to them.

There are no tests in the patch yet. Any recommendation on tests? (just check that the member exists and has an 'int' value?

----------
components: Library (Lib)
files: expose_msi.c_handles.diff
keywords: patch
messages: 135401
nosy: loewis, markm
priority: normal
severity: normal
status: open
title: Support more of MSI api by exposing handles
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21914/expose_msi.c_handles.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12026>
_______________________________________

From report at bugs.python.org  Sat May  7 07:00:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 May 2011 05:00:03 +0000
Subject: [issue12025] strangely missing separator in "resource" table
In-Reply-To: <1304734977.84.0.0748743077356.issue12025@psf.upfronthosting.co.za>
Message-ID: <1304744403.29.0.0864686242014.issue12025@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sorry, I can't see anything wrong here (with FF 4.0 too).  Can you attach a screenshot?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12025>
_______________________________________

From report at bugs.python.org  Sat May  7 08:34:26 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 06:34:26 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1304750066.68.0.770885016003.issue9516@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a v2 of the patch which adresses ?ric's comments.

I haven't changed the CompileError handling though, that would change a test failure into a test error. IMHO test errors should only happend due to bugs in the test code.

AddCleanup is neat trick, I keep forgetting the nice new features that were added to unittest recently.

The assertEquals issue is one that keeps biting me, I know the correct form is assertEqual but every single time I write tests I keep using assertEquals for some reason.  Maybe its time for some electroshock therapy...

----------
Added file: http://bugs.python.org/file21915/issue9516-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sat May  7 08:40:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 06:40:01 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304750401.24.0.61313693717.issue11994@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"Also, the segfault only occurs when python is
compiled with optimizations and run under valgrind."

This says to me that the segfault is not a Python issue.
What change do you expect in the Python source code?
If none, this issue should be closed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11994>
_______________________________________

From report at bugs.python.org  Sat May  7 08:45:38 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 06:45:38 +0000
Subject: [issue12001] Extend json.dumps to handle N-triples strings
In-Reply-To: <1304518731.8.0.661491806451.issue12001@psf.upfronthosting.co.za>
Message-ID: <1304750738.32.0.624497055041.issue12001@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that the json module should stick with the json definition. Adding other stuff would take it even further from simplejson.
A conversion function, if short enough, could be posted on the cookbook.

----------
nosy: +terry.reedy
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12001>
_______________________________________

From report at bugs.python.org  Sat May  7 09:05:24 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 07 May 2011 07:05:24 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1304751924.97.0.891781364015.issue12021@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Sat May  7 09:19:44 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 07:19:44 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1304752784.44.0.854012437543.issue10154@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch implements the change that Marc-Andre proposed.

I intend to apply this patch to all active branches later today (after some more testing)

----------
keywords: +patch
Added file: http://bugs.python.org/file21916/issue10154.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Sat May  7 09:23:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 07:23:50 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1304753030.01.0.318221754684.issue12003@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified bug on winxp with 2.7
xrangef [5, 4, 3, 2, 1, 0]
py26 []
py27 [5, 4, 3, 2, 1, 0, -1, -2]
v1 [5, 4, 3, 2, 1, 0]
v2 [5, 4, 3, 2, 1, 0]
v3 [5, 4, 3, 2, 1, 0]
-----------------------
xrangef [5, 3, 1, -1, -3]
py26 []
py27 [5, 3, 1, -1, -3, -5]
v1 [5, 3, 1, -1, -3]
v2 [5, 3, 1, -1, -3]
v3 [5, 3, 1, -1, -3]

The problem is that -1 should instead be +1 for negative steps. The 2.6 version completely failed for negative steps because the comparison needs to be reversed. The doc example could add "for positive steps. For negative steps, use '+1' instead of '-1'". Or change expression to
islice(count(start, step), (stop-start+step-1+2*(step<0))//step)
(the addition is  +2*(step<0)).
Or change -1 to +(-1 if step>0 else 1). I tested both.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Sat May  7 09:33:28 2011
From: report at bugs.python.org (Jan Killian)
Date: Sat, 07 May 2011 07:33:28 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1304753608.37.0.78101197809.issue10466@psf.upfronthosting.co.za>


Changes by Jan Killian <jan.killian at gmail.com>:


----------
nosy: +iki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Sat May  7 09:37:19 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 07:37:19 +0000
Subject: [issue11916] A few errnos from OSX
In-Reply-To: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>
Message-ID: <1304753839.56.0.474563828209.issue11916@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This shell-fragment lists which names in /usr/include/sys/errno don't exist in errnomodule.h:

$ grep '#define[      ]*E' /usr/include/sys/errno.h  | 
    awk '{ print $2 }' | grep -v '^ELAST$' | 
    while read name; do 
        grep -q $name Modules/errnomodule.c || echo $name; 
    done | sort

The following names in your list are already part in errnomodule.h:

* ECANCELED
* ENOTSUP

The patch looks fine otherwise. I'm currently rebuilding python3.3 and will commit the patch if everything works properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11916>
_______________________________________

From report at bugs.python.org  Sat May  7 09:41:02 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 07:41:02 +0000
Subject: [issue11916] A few errnos from OSX
In-Reply-To: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>
Message-ID: <1304754062.02.0.972967297859.issue11916@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

And the patch works properly, with the patch applied (except for the two names I mentioned earlier):


$ DYLD_FRAMEWORK_PATH=$PWD ./python.exe
Python 3.3a0 (default:5fa92a47016c+, May  7 2011, 09:36:44) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import errno
>>> errno.EAUTH
80
>>> errno.ECANCELED
89
>>> errno.ENOTSUP
45
>>> errno.EPROGMISMATCH
75
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11916>
_______________________________________

From report at bugs.python.org  Sat May  7 09:41:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 07:41:48 +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: <1304754108.98.0.286256519281.issue12016@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

u'' in 2.7.1 also, on winxp

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Sat May  7 09:43:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 07:43:27 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304754207.97.0.334347211814.issue12017@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12017>
_______________________________________

From report at bugs.python.org  Sat May  7 09:48:37 2011
From: report at bugs.python.org (Nicolas Bareil)
Date: Sat, 07 May 2011 07:48:37 +0000
Subject: [issue12000] SSL certificate verification failed if no dNSName entry
	in subjectAltName
In-Reply-To: <1304508952.88.0.678717772317.issue12000@psf.upfronthosting.co.za>
Message-ID: <1304754517.36.0.568196346631.issue12000@psf.upfronthosting.co.za>


Nicolas Bareil <nico at chdir.org> added the comment:

Hello Mads

> Until now Python failed to the safe side by not matching on 
> subjectAltName iPAddress but also not falling back to commonName
> if they were specified. AFAICS, with this change it is possible to 
> create strange certificates that Python would accept when an IP 
> address matched commonName but other implementations would reject 
> because of iPAddress mismatch.

Good point! But I think we already have this issue with a certificate 
like this one:

cert = { 'subject': ((('commonName', '192.168.1.1'),),)}
ok(cert, '192.168.1.1')

Do you think this test should fail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12000>
_______________________________________

From report at bugs.python.org  Sat May  7 09:59:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 07:59:13 +0000
Subject: [issue11916] A few errnos from OSX
In-Reply-To: <1303682275.04.0.607267182641.issue11916@psf.upfronthosting.co.za>
Message-ID: <E1QIcPv-0000iJ-OU@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2f978b4c02ad by Ronald Oussoren in branch 'default':
Closes Issue 11916: Add a number of MacOSX specific definitions to the errno module.
http://hg.python.org/cpython/rev/2f978b4c02ad

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11916>
_______________________________________

From report at bugs.python.org  Sat May  7 10:00:36 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 08:00:36 +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: <1304755236.07.0.988753366153.issue10910@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


Removed file: http://bugs.python.org/file21728/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Sat May  7 10:03:53 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 May 2011 08:03:53 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304755433.67.0.680967972906.issue11994@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Terry J. Reedy <report at bugs.python.org> wrote:
> "Also, the segfault only occurs when python is
> compiled with optimizations and run under valgrind."
>
> This says to me that the segfault is not a Python issue.
> What change do you expect in the Python source code?
> If none, this issue should be closed.

I think that the passage you quoted is not a strong argument for closing
the issue. I've been using Valgrind for several years, and I've never
encountered a situation where Valgrind was wrong. This includes situations
where a bug only occurs with optimizations turned on.

If anything, the fact that it so far only occurs with gcc-4.3 might
be a reason. Even so, recently an issue was kept open until someone
(I think Victor) proved that it was a compiler bug.


I'm not sure what to make of your question and its conclusion. Debugging
Valgrind issues or compiler bugs takes a lot of time, so the requirement
to pinpoint the exact problem in order to keep an issue open seems too
strict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11994>
_______________________________________

From report at bugs.python.org  Sat May  7 10:07:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 08:07:34 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1304755654.62.0.74838941529.issue10154@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/issue10154>
_______________________________________

From report at bugs.python.org  Sat May  7 10:13:14 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 08:13:14 +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: <1304755994.15.0.609809429068.issue10910@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The problem is that pyport tries to replace the ctypes definion of the isascii(ch) and related functions by a replacement that works better with UTF-8 on FreeBSD and OSX. That replacement is incompatible with the localfwd.h header.

The attached patch is a very crude hack that should fix the issue for this. This assumes that Python itself won't be compiled with C++ though, and might cause problems in C++ programs that use locale.h instead of localfwd.h.

As such I won't apply the patch just yet, the patch needs review from someone that's more experienced w.r.t. C++.

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file21917/issue10910.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10910>
_______________________________________

From report at bugs.python.org  Sat May  7 10:13:45 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 08:13:45 +0000
Subject: [issue5154] OSX broken poll testing doesn't work
In-Reply-To: <1233786742.9.0.12404457396.issue5154@psf.upfronthosting.co.za>
Message-ID: <1304756025.02.0.959105925959.issue5154@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5154>
_______________________________________

From report at bugs.python.org  Sat May  7 10:18:28 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 07 May 2011 08:18:28 +0000
Subject: [issue11607] Apllication crashes when saving file
In-Reply-To: <1300551000.41.0.0747067514323.issue11607@psf.upfronthosting.co.za>
Message-ID: <1304756308.69.0.317152575897.issue11607@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

There is not enough information in the description to even know which program crashes, let alone to reproduce the problem.

I'm therefore closing this issues. Feel free to reopen the issue when you can supply more information (see the questions in the two other responses in this issue).

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11607>
_______________________________________

From report at bugs.python.org  Sat May  7 10:20:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 08:20:46 +0000
Subject: [issue11999] sporadic failure in test_mailbox
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304756446.98.0.489492615986.issue11999@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand anything, but thanks for fixing it :-) (Or at least trying to fix it, buildbots will tell us.)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________

From report at bugs.python.org  Sat May  7 10:30:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 08:30:35 +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: <1304757035.65.0.374247032369.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> @haypo, @pitrou: Are there any objections to removing test_big_buffer()
from Lib/test/test_zlib.py?

I now agree Antoine: the test is useless. It can be removed today.

About mmap: add a new test for this issue (mmap on Mac OS X and F_FULLSYNC)  is a good idea. I suppose that we will need to backport the F_FULLSYNC fix too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 10:34:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 08:34:57 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1304757297.83.0.277518497424.issue11995@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Isn?t the root problem that pydoc uses import rather than imp or PEP 302 things?  We could change that.

It's possible to get the documentation of some module without loading them: pydoc already supports get_source() method of a module loader.

But my concern is more about C modules: you have to load them to get their documentation, but you can never a unload C modules (you have to exit Python).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11995>
_______________________________________

From report at bugs.python.org  Sat May  7 10:40:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 08:40:10 +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: <1304757610.12.0.715420612554.issue12016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

So the correct result for b'\xff\n'.decode('gb2312', 'replace') is u'?\n'?

----------
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Sat May  7 11:01:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 09:01:27 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304758887.2.0.143952046493.issue9971@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops... It hadn't jumped at me earlier, but the patch is actually problematic performance-wise. The reason is that it doesn't buffer data at all, so small readintos become slower (they have to go through raw I/O every time):

$ ./python -m timeit -s "f=open('LICENSE', 'rb'); b = bytearray(4)" \
  "f.seek(0)" "while f.readinto(b): pass"
-> without patch: 2.53 msec per loop
-> with patch: 3.37 msec per loop

$ ./python -m timeit -s "f=open('LICENSE', 'rb'); b = bytearray(128)" \
  "f.seek(0)" "while f.readinto(b): pass"
-> without patch: 90.3 usec per loop
-> with patch: 103 usec per loop

The patch does make large reads faster, as expected:

$ ./python -m timeit -s "f=open('LICENSE', 'rb'); b = bytearray(4096)" \
  "f.seek(0)" "while f.readinto(b): pass"
-> without patch: 13.2 usec per loop
-> with patch: 6.71 usec per loop

(that's a good reminder for the future: when optimizing something, always try to measure the "improvement" :-))

One solution would be to refactor _bufferedreader_read_generic() to take an existing buffer, and use that.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sat May  7 11:06:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 May 2011 09:06:58 +0000
Subject: [issue11962] Buildbot reliability
In-Reply-To: <1304145791.54.0.116120198788.issue11962@psf.upfronthosting.co.za>
Message-ID: <1304759218.78.0.153562373678.issue11962@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think the FreeBSD bot changes are working out fine. The Ubuntu-PPC
issues were unrelated, so I'm closing this.

----------
keywords: +buildbot
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11962>
_______________________________________

From report at bugs.python.org  Sat May  7 11:08:39 2011
From: report at bugs.python.org (zy)
Date: Sat, 07 May 2011 09:08:39 +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: <1304759319.16.0.657010046531.issue12016@psf.upfronthosting.co.za>


zy <cdqzzy at gmail.com> added the comment:

> So the correct result for b'\xff\n'.decode('gb2312', 'replace') is u'?\n'?

I think it should be so. This behavior does not leave out possible information, has no side-effect on later decodings, and should the '\n'  indeed be redundant, an output of u'?\n' would unlikely cause confusions.

Though, I have no knowledge on this subject code-wise. If a change of the behavior will have an impact on performance, maybe the change should not come in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Sat May  7 11:21:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:21:44 +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: <1304760104.18.0.60308675149.issue12016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_codecs_cn implements different multibyte encodings: gb2312, gbkext, gbcommon, gb18030ext, gbk, gb18030.

And there are other Asian multibyte encodings: big5 family, ISO 2202 family, JIS family, korean encodings (KSX1001, EUC_KR, CP949, ...), Big5, CP950, ...

All of them ignore the all bytes if one byte of a multibyte sequence is invalid (lile 0xFF 0x0A: replaced by ? instead of ?\n using replace error handler).

I don't think that you can/should patch only one encoding: we should use the same rule for all encodings.

By the way, do you have any document explaining which result is the good one (? or ?\n)? For UTF-8, we have well defined standards explaining exactly what to do with invalid byte sequences => see issue #8271. It is easy to fix the decoders, but I would like to be sure that your proposed change is the right way to decode these encodings.

Change the multibyte encodings can also concern the security. Read for example the following section "Check byte strings before decoding them to character strings" of my book:
http://www.haypocalc.com/tmp/unicode-2011-03-25/html/issues.html#check-byte-strings-before-decoding-them-to-character-strings
(https://github.com/haypo/unicode_book/wiki)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Sat May  7 11:23:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:23:07 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304760187.93.0.0628478312125.issue12012@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Please avoid "negative" constants. Calling it HAS_SSLv2 would be fine.

I reused the term from ssl.h (#ifdef OPENSSL_NO_SSL2), but yes we can use a different name.

> Also, there should be some doc update mentioning that PROTOCOL_SSLv2
> is not always present.

Ok, I will do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Sat May  7 11:23:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 09:23:39 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304760219.25.0.441505412411.issue9971@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A solution could be to use overlapped I/O on the named pipe handles.
The first poll() would call ReadFile() with a tiny value (1?) and store an object wrapping the OVERLAPPED structure. Subsequent poll() or recv() would re-use that structure until the overlapped read succeeds.
The hEvent in the OVERLAPPED structure should be usable in WFMO fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sat May  7 11:35:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:35:19 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1304705564.12.0.199639005668.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304760914.13903.6.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Thanks, Victor.  I suspect we're going to need to be a bit more
> careful, though:  when the extra tests were added for math.log, it
> turned out that it had all sorts of strange special-case behaviour on
> various platforms.
> 
> So I suspect that even on platforms that have log2 natively, it'll be
> necessary to factor out special cases and deal with those first, only
> passing positive finite floats onto the system log2.  Take a look at
> m_log and the comment directly above it to see how that works.

Oh, I see:

/*                                                                              
    Various platforms (Solaris, OpenBSD) do nonstandard things for
log(0),      
    log(-ve), log(NaN).  Here are wrappers for log and log10 that deal
with     
    special values directly, passing positive non-special values through
to     
    the system
log/log10.                                                       
 */      

> I'd also like to check in the non-system version first, just to give
> it a thorough test on the buildbots, before adding in the version that
> uses the system log2 when available.

Yes, we can use log2() only for the "x > 0.0" case. My secret plan was
to check system log2() using the buildbots. But if we know that system
log() only works correctly with strictly positive numbers, it's faster
to directly only use system log2() for x > 0.0.

Updated patch (version 3) implements that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Sat May  7 11:38:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:38:40 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304761120.94.0.262235166201.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(Oh, I hit the wrong keyboard shortcut and sent my email too fast)

You can commit issue11888.patch	first if you would like to test it.

In this case, here is a patch to use system log2(), patch to apply *after* issue11888.patch. It only uses log2() if x > 0.0.

----------
Added file: http://bugs.python.org/file21918/issue11888-part2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Sat May  7 11:38:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:38:52 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304761132.45.0.371772725679.issue11888@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21897/issue11888-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Sat May  7 11:41:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:41:01 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304761261.71.0.72569762041.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

By the way, issue11888.patch is just fine: you can commit it. I like your frexp "trick" to improve the accuracy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Sat May  7 11:42:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 09:42: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: <E1QIe25-0006OC-S9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 201dcfc56e86 by Nadeem Vawda in branch '2.7':
Issue #11277: Remove useless test from test_zlib.
http://hg.python.org/cpython/rev/201dcfc56e86

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 11:43:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:43:46 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1304761426.25.0.791256414523.issue11873@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> You are right that I got the regex wrong (I'm bad at regexes), but
> in fact it is fine the way it is.  Since there's no r, the regex
> is actually "ba[^/]$", which is exactly what I meant.

What about Windows? tempfile.mkdtemp(prefix='bar') can generate ...\tmpxxbaxx\... Or compileall does first normalize the path?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Sat May  7 11:49:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:49:32 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1304761772.06.0.412785996377.issue10419@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +benjamin.peterson, georg.brandl
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Sat May  7 11:51:54 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 May 2011 09:51:54 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304761914.21.0.674637269947.issue11994@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The segfault also occurs with a self-compiled gcc-4.4.6, but not
with gcc-4.5.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11994>
_______________________________________

From report at bugs.python.org  Sat May  7 11:52:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:52:54 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Patch to optimize this: make it 10 times faster.

Try attached benchmark script. On a debug build I got the following results:
 * original: 299.8 ms
 * patched: 23.2 ms

I expected a factor of 10 because it uses a C implementation of rot13 instead of an hand made Python implementation.

----------
components: Library (Lib)
files: python27_this_rot13.patch
keywords: patch
messages: 135432
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize import this (patch to make it 10x faster)
versions: Python 2.7
Added file: http://bugs.python.org/file21919/python27_this_rot13.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 11:53:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:53:05 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304761985.59.0.396483514627.issue12027@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file21920/bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 11:53:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 09:53:17 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304761997.64.0.598989665312.issue12027@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +lemburg, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 11:56:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 09:56:30 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304762190.0.0.23925451145.issue12027@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Barry, 2.6?

----------
nosy: +barry, benjamin.peterson
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 12:00:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 10:00:05 +0000
Subject: [issue11668] _multiprocessing.Connection.poll with timeout uses
	polling under Windows
In-Reply-To: <1301012856.06.0.501822966935.issue11668@psf.upfronthosting.co.za>
Message-ID: <1304762405.72.0.526872303226.issue11668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A solution could be to use overlapped I/O on the named pipe handles.
The first poll() would call ReadFile() with a tiny value (1?) and store an object wrapping the OVERLAPPED structure. Subsequent poll() or recv() would re-use that structure until the overlapped read succeeds.
The hEvent in the OVERLAPPED structure should be usable in WFMO fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11668>
_______________________________________

From report at bugs.python.org  Sat May  7 12:00:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 10:00:30 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304762430.01.0.131629670635.issue9971@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Uh, sorry for the last message (about overlapped I/O), wrong issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sat May  7 12:00:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 10:00:39 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304762439.39.0.315337728851.issue9971@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
Removed message: http://bugs.python.org/msg135425

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sat May  7 12:00:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 10:00:44 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304762444.44.0.211989738543.issue9971@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
Removed message: http://bugs.python.org/msg135435

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sat May  7 12:01:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:01:00 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304762460.2.0.823890484797.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I mistakenly removed your pending_signals-2 patch
> I'm really sorry about this, could you re-post it?

No problem, anyway I worked on a new version in the train.

> So, if anything, you shouldn't check for a pending signal [in sigwait]

Right, fixed in the new patch.

--

pending_signals-3.patch:
 - don't check for pending signals in sigwait()
 - pthread_kill() doc: it is not a good idea to say that pthread_kill() with signum=0 can be used to check if a thread identifier is valid => such test does crash (SIGSEGV) on my Linux box. I changed the doc to say that it can be used to check if a thread is still running (which is different).
 - add a dedicated test for sigpending()
 - doc: explain how to get a thread identifier for pthread_kill()
 - don't compile pthread_kill() without threads: you cannot get a valid thread identifier without the _thread module

I think that the patch is ready to be commited. Anyone for a last review? (antoine, neologix?)

----------
Added file: http://bugs.python.org/file21921/pending_signals-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 12:02:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:02:14 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304762534.32.0.0640629304962.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: we might expose pth_raise() which is similar to pthread_kill(), but... pth support was deprecated by the PEP 11 and pth support will be removed from Python 3.3 source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 12:05:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:05:24 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304762724.78.0.373070622868.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About signalfd(): this patch doesn't provide any information or tool to decode data written to the file descriptor. We should expose the signalfd_siginfo structure or you cannot handle more than one signal (how do you know which signal numbers were raised?). Example with ctypes:

class signalfd_siginfo(Structure):
    _fields_ = (
        ('ssi_signo', c_uint32),    # Signal number
        ('ssi_errno', c_int32),     # Error number (unused)
        ('ssi_code', c_int32),      # Signal code
        ('ssi_pid', c_uint32),      # PID of sender
        ('ssi_uid', c_uint32),      # Real UID of sender
        ('ssi_fd', c_int32),        # File descriptor (SIGIO)
        ('ssi_tid', c_uint32),      # Kernel timer ID (POSIX timers)
        ('ssi_band', c_uint32),     # Band event (SIGIO)
        ('ssi_overrun', c_uint32),  # POSIX timer overrun count
        ('ssi_trapno', c_uint32),   # Trap number that caused signal
        ('ssi_status', c_int32),    # Exit status or signal (SIGCHLD)
        ('ssi_int', c_int32),       # Integer sent by sigqueue(2)
        ('ssi_ptr', c_uint64),      # Pointer sent by sigqueue(2)
        ('ssi_utime', c_uint64),    # User CPU time consumed (SIGCHLD)
        ('ssi_stime', c_uint64),    # System CPU time consumed (SIGCHLD)
        ('ssi_addr', c_uint64),     # Address that generated signal
                                    # (for hardware-generated signals)
        ('_padding', c_char * 46),  # Pad size to 128 bytes (allow for
                                    # additional fields in the future)
    )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 12:07:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:07:18 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304762838.12.0.883579579237.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

wakeup_signum.patch: simple patch to write the signal number (as a single byte) instead of just b'\x00' into the wake up file descriptor. It gives the ability to watch more than one signal and be able to know which one was raised. Included tests demonstrate the feature. The doc explains how to decode data written to the file descriptor.

----------
Added file: http://bugs.python.org/file21922/wakeup_signum.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 12:11:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:11:04 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304763064.79.0.158883695804.issue8407@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21883/pending_signals.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 12:19:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:19:16 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304763556.95.0.699897213634.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

pending_signals-3.patch: doc nit, the link to Thread.ident doesn't work. The doc should be replaced by something like:
              
   *thread_id* can be read from the :attr:`~threading.Thread.ident` attribute   
   of a :class:`threading.Thread` object.  For example,                         
   ``threading.current_thread().ident`` gives the identifier of the current     
   thread.

... but ident or Thread are not link, I don't know why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 12:24:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:24:45 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

I don't know why threading._get_ident() (which is _thread.get_ident()) is private: this function is safe.

This function becomes useful with pthread_kill() which will be added by #8407.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 135441
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: threading._get_ident(): remove it in the doc and make it public
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Sat May  7 12:26:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:26:35 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304763995.05.0.10820068852.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The threading has a function to get directly the identifier of the current thread: threading._get_ident() instead of threading.current_thread().ident. I think that threading._get_ident() is more reliable to threading.current_thread().ident because Thread.ident can be None in some cases. I created the issue #12028 to decide what to do with this function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 12:26:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:26:38 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1304763998.76.0.565788611217.issue12028@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that threading._get_ident() is more reliable than threading.current_thread().ident because Thread.ident can be None in some cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Sat May  7 12:51:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 10:51:40 +0000
Subject: [issue11994] [2.7/gcc-4.4.3] Segfault under valgrind in string.split()
In-Reply-To: <1304490083.54.0.954268158291.issue11994@psf.upfronthosting.co.za>
Message-ID: <1304765500.96.0.965052859371.issue11994@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

GCC does have bugs: see a recent example with a development version of GCC 4.6 => #9880 (the bug was fixed before the final release of GCC 4.6).

If you would like to go futher, you should open a bug report in GCC bug tracker (not in the Python bug tracker).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11994>
_______________________________________

From report at bugs.python.org  Sat May  7 13:12:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 11:12:45 +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: <E1QIfRB-00037i-2F@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d5d4f2967879 by Nadeem Vawda in branch '3.1':
Issue #11277: Add tests for mmap crash when using large sparse files on OS X.
http://hg.python.org/cpython/rev/d5d4f2967879

New changeset e447a68742e7 by Nadeem Vawda in branch '3.2':
Merge: #11277: Add tests for mmap crash when using large sparse files on OS X.
http://hg.python.org/cpython/rev/e447a68742e7

New changeset bc13badf10a1 by Nadeem Vawda in branch 'default':
Merge: #11277: Add tests for mmap crash when using large sparse files on OS X.
http://hg.python.org/cpython/rev/bc13badf10a1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 13:17:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 11:17:54 +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: <E1QIfWB-0003Rc-5a@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8d27d2b22394 by Nadeem Vawda in branch '2.7':
Issue #11277: Add tests for mmap crash when using large sparse files on OS X.
http://hg.python.org/cpython/rev/8d27d2b22394

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 13:32:47 2011
From: report at bugs.python.org (zy)
Date: Sat, 07 May 2011 11:32:47 +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: <1304767967.63.0.73820705744.issue12016@psf.upfronthosting.co.za>


zy <cdqzzy at gmail.com> added the comment:

I do not have documents on this subject. Though, I found that GNU iconv(1) behaves the same as my proposed behavior. My reading of the source code suggests that iconv(1) treat all encodings equally, which I think should also be true for python.

As of security concerns, I do not think the change in decoding function itself would introduce any security vulnerabilities. If a security issue arises because of the proposed change, there must be improper code out side of python, which is out of python's control. That said, the proposed change is unlikely to introduce new security vulnerability, as all it does in effect is retaining a few ascii characters in the string to the output as opposed to removing.  In the issue of wordpress, if we suppose that wordpress was written in python, and that the attacker was using gb2312 encoded strings instead of gbk, then my proposed change would by chance fix the issue, as the backslash would be retained when we decode the string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Sat May  7 13:57:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 11:57:50 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1304721629.88.0.0214628335849.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110507115741.GA13744@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@Nadeem: note that the committed versions of the tests would not
show up the Mac OS X mmap() bug AFAIK, because there is an
intermediate .close() of the file to be mmapped.  The OS X bug is
that the VMS/VFS interaction fails to provide a valid memory
region for <<pages which are not yet physically present on disc>>
- i.e. there is no true sparse file support as on Linux, which
simply uses references to a single COW zero page.
(I've not tried it out for real yet, but i'm foolish like a prowd
cock, so i've looked at the changeset :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 13:58:56 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 07 May 2011 11:58:56 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <4DC533F9.7020601@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> Patch to optimize this: make it 10 times faster.
> 
> Try attached benchmark script. On a debug build I got the following results:
>  * original: 299.8 ms
>  * patched: 23.2 ms
> 
> I expected a factor of 10 because it uses a C implementation of rot13 instead of an hand made Python implementation.

It's a bit late for an April 1st patch, but +1 for the fun of it :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 14:05:52 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 12:05:52 +0000
Subject: [issue11277] Crash with mmap and sparse files on Mac OS X
In-Reply-To: <1304721629.88.0.0214628335849.issue11277@psf.upfronthosting.co.za>
Message-ID: <20110507120544.GA21698@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Of course this may also be intentional, say.
But then i would vote against it :), because it's better the
tests bring out errors than end-user apps.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 14:14:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 May 2011 12:14:52 +0000
Subject: [issue12023] non causal behavior
In-Reply-To: <1304722385.56.0.574647531565.issue12023@psf.upfronthosting.co.za>
Message-ID: <1304770492.53.0.204561773535.issue12023@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In 3.x, yes (the nonlocal keyword).  Not in 2.7, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12023>
_______________________________________

From report at bugs.python.org  Sat May  7 14:19:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 12:19:23 +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: <E1QIgTh-0007kv-PS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9b9f0de19684 by Nadeem Vawda in branch '2.7':
Issue #11277: Fix tests - crash will not trigger if the file is closed and reopened.
http://hg.python.org/cpython/rev/9b9f0de19684

New changeset b112c72f8c01 by Nadeem Vawda in branch '3.1':
Issue #11277: Fix tests - crash will not trigger if the file is closed and reopened.
http://hg.python.org/cpython/rev/b112c72f8c01

New changeset a9da17fcb564 by Nadeem Vawda in branch '3.2':
Merge: #11277: Fix tests - crash will not trigger if the file is closed and reopened.
http://hg.python.org/cpython/rev/a9da17fcb564

New changeset b3a94906c4a0 by Nadeem Vawda in branch 'default':
Merge: #11277: Fix tests - crash will not trigger if the file is closed and reopened.
http://hg.python.org/cpython/rev/b3a94906c4a0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 14:20:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 07 May 2011 12:20:51 +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: <1304770851.24.0.685842930439.issue11877@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I'll attach 11877.4.diff

A couple comments:

static PyObject *
posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
{
    PyObject *retval = NULL;
    auto PyObject *fdobj;
    auto int full_fsync = 1;

Why are you using the "auto" storage class specifier? I know that "explicit is better than implicit", but I really can't see a good reason for using it here (and anywhere, see http://c-faq.com/decl/auto.html).

# ifdef __APPLE__
    res = fcntl(fd, F_FULLFSYNC);
# endif
# ifdef __NetBSD__
    res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
# endif

Since __APPLE__ and __NetBSD__ are exclusive, you could use something like
# if defined(__APPLE__)
    res = fcntl(fd, F_FULLFSYNC);
# elif defined(__NetBSD__)
    res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
# endif

Do you really need to use goto for such a simple code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat May  7 14:23:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 12:23:20 +0000
Subject: [issue11999] sporadic failure in test_mailbox on FreeBSD
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <20110507122310.GB21698@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

That's really a good one.
(In my eyes.)

----------
title: sporadic failure in test_mailbox -> sporadic failure in test_mailbox on FreeBSD

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________

From report at bugs.python.org  Sat May  7 14:27:40 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 07 May 2011 12:27:40 +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: <1304771260.1.0.986473975461.issue11277@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

sdaoden> @Nadeem: note that the committed versions of the tests would not
sdaoden> show up the Mac OS X mmap() bug AFAIK, because there is an
sdaoden> intermediate .close() of the file to be mmapped.

Thanks for catching that. Should be fixed now.

haypo> I now agree Antoine: the test is useless. It can be removed today.
haypo>
haypo> About mmap: add a new test for this issue (mmap on Mac OS X and
haypo> F_FULLSYNC)  is a good idea.

Done and done.

haypo> I suppose that we will need to backport the F_FULLSYNC fix too.

It has already been backported, as changeset 618c3e971e80.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat May  7 14:28:48 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 07 May 2011 12:28:48 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304771328.85.0.128410783134.issue12027@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

That's a good one, but um, no not for 2.6, unless you can argue that a delay in obtaining the received wisdom of The Timbot is a serious security hole in Python.

Bag of ham.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 14:50:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 12:50:07 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1304770851.24.0.685842930439.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110507124958.GA31845@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat,  7 May 2011 14:20:51 +0200, Charles-Fran?ois Natali wrote:
> I really can't see a good reason for using it here (and
> anywhere, see http://c-faq.com/decl/auto.html).

You're right.

> Why are you using the "auto" storage class specifier? I know
> that "explicit is better than implicit"

Yup.  I'm doing what is happening for real in (x86) assembler.
Thus "auto" means (at a glance!) that this one will need space on
the stack.
(Conversely i'm not using "register" because who knows if that is
really true?  ;))

> Do you really need to use goto for such a simple code?

Yup.  Ok, this is more complicated.  The reason is that my funs
have exactly one entry point and exactly one place where they're
left.  This is because we here do manual instrumentalisation as in

ret
fun(args)
{
    locals
    s_NYD_ENTER;

    assertions

    ...

jleave:
    s_NYD_LEAVE;
    return;

[maybe only, if large: possibly "predict-false" code blocks]

[possible error jumps here
    goto jleave;]
}

We're prowd of that.  N(ot)Y(et)D(ead) is actually pretty cool,
i've used debuggers exactly 5 times in the past about ten years!
I don't even know exactly *how to use debuggers*.  8---} (NYD can
do backtracing, or, with NDEBUG and optional, profiling.)
A really good optimizing compiler will produce the very same code!
And i love nasm, but it's pretty non-portable.
But C is also nice.

But of course i can change this (in C) to simply use return, this
is easy here, no resources to be freed.

Thanks for looking at this, by the way.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat May  7 14:52:40 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 12:52:40 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1304770851.24.0.685842930439.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110507125231.GB31845@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Sat,  7 May 2011 14:20:51 +0200, Charles-Fran?ois Natali wrote:
> # ifdef __APPLE__
>     res = fcntl(fd, F_FULLFSYNC);
> # endif
> # ifdef __NetBSD__
>     res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
> # endif
> 
> Since __APPLE__ and __NetBSD__ are exclusive, you could use something like
> # if defined(__APPLE__)
>     res = fcntl(fd, F_FULLFSYNC);
> # elif defined(__NetBSD__)
>     res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
> # endif

Yes, you're right, i'll update the patch accordingly.

--
Steffen, sdaoden(*)(gmail.com)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat May  7 14:57:37 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 12:57:37 +0000
Subject: [issue11999] sporadic failure in test_mailbox
In-Reply-To: <1304507847.24.0.74411710498.issue11999@psf.upfronthosting.co.za>
Message-ID: <1304773057.75.0.269577861733.issue11999@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

This tracker - sorry!
(I surely will try to write and offer a patch for the tracker,
but first i need to understand that mailbox.py jungle for
#11935, next week.)

----------
title: sporadic failure in test_mailbox on FreeBSD -> sporadic failure in test_mailbox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11999>
_______________________________________

From report at bugs.python.org  Sat May  7 15:06:00 2011
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 07 May 2011 13:06:00 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1304773560.13.0.749205904862.issue11969@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Do things like this in the REPL are known not to work. Things are not protected in the if __name__ block so we can import the script properly to run it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Sat May  7 15:27:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 13:27:03 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304774823.45.0.987293002184.issue9205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch. Much of it consists of changes in the Windows Connection implementation, where I had to use overlapped I/O in order to use WaitForMultipleObjects on named pipes.

test_concurrent_futures sometimes blocks (under Windows), I'll try to debug.

----------
nosy: +brian.curtin
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file21923/sentinels2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Sat May  7 15:37:36 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 13:37:36 +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: <20110507133727.GA57518@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

11877.5.diff incorporates all changes suggested by
Charles-Fran??ois except for the 'auto' keyword, which is extremely
important and which would need to be invented if it would not
yet exist.

I'm dropping the old stuff.  And i think this is the final version
of the patch.  I've changed the default argument to 'True' as
i really think it's better to be on the safe side here.  (The
french are better off doing some gracy and dangerous sports to
discover edges of life!)  I'm still of the opinion that this
should be completely hidden, but since it's completely transparent
wether a Python function gets yet another named argument or not...

So, thanks to Ronald, i detected that also NetBSD introduced
a FDISKSYNC flag in 2005 and that you really need fsync_range()
there (at least by definition)!  How could they do that?  But i'm
also happy to see that all other systems try hard to achieve
security transparently and by default and unless i missed
something once again.

----------
Added file: http://bugs.python.org/file21924/11877.5.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
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=True)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,12 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   The POSIX standart only 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.  On operating systems where it is
+   necessary and possible the optional *full_fsync* argument can be used to
+   initiate additional steps to synchronize the physical backing store.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2121,13 +2121,46 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_fsync=True)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"full_fsync forces flush of disk caches in case fsync() alone is not enough.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    auto PyObject *fdobj;
+    auto int full_fsync = 1;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        return NULL;
+
+    /* See issue 11877 discussion */
+# if ((defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC))
+    if (full_fsync != 0) {
+        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__
+        res = fcntl(fd, F_FULLFSYNC);
+#  elif defined __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0)
+            return posix_error();
+        Py_INCREF(Py_None);
+        return Py_None;
+    } else
+# endif
+        return posix_fildes(fdobj, fsync);
 }
 #endif /* HAVE_FSYNC */
 
@@ -9472,7 +9505,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Sat May  7 15:38:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 13:38:24 +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: <1304775504.68.0.39697739724.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21749/11877.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat May  7 15:38:29 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 07 May 2011 13:38:29 +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: <1304775509.22.0.201429912014.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21771/11877.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat May  7 16:07:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 14:07:07 +0000
Subject: [issue11072] Add MLSD command support to ftplib
In-Reply-To: <1296430651.22.0.68039486547.issue11072@psf.upfronthosting.co.za>
Message-ID: <E1QIi9v-0006FN-Kn@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 153bd8fc22c7 by Giampaolo Rodola' in branch 'default':
#11072- applying http://bugs.python.org/review/11072/show suggestions
http://hg.python.org/cpython/rev/153bd8fc22c7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11072>
_______________________________________

From report at bugs.python.org  Sat May  7 16:15:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 14:15:54 +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: <1304777754.35.0.889009689649.issue12013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

$ python3.1 -m test.regrtest

If your distribution removes tests from the binary package, this won?t work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Sat May  7 16:19:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 14:19:32 +0000
Subject: [issue11963] Remove human verification from test suite (test_parser
	and test_subprocess)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1304777972.37.0.374897089687.issue11963@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please feel free to improve titles; we?re a team, there?s no ego in bug title phrasing :)  I did so on at least one bug of yours; hope you didn?t consider it rude.

Are you asking about the docstring of the test module or the reST doc of test.support?  A brief mention of test.script_helper (and possibly the other undocumented test helpers) could be added in either or both IMO, but just to let people know about about the file and go read it or pydoc it; we don?t want to spend too much time documenting private modules with no compat constraints.

----------
title: Use real assert* for test_trigger_memory_error (test_parser) -> Remove human verification from test suite (test_parser and test_subprocess)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11963>
_______________________________________

From report at bugs.python.org  Sat May  7 17:09:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:09:46 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1304780986.97.0.366935592017.issue10713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Would you be interested in experimenting and/or reading the code to find the anwser and propose a doc patch?

----------
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Sat May  7 17:10:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 May 2011 15:10:31 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1304781031.49.0.7150998422.issue10713@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/issue10713>
_______________________________________

From report at bugs.python.org  Sat May  7 17:12:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:12:44 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304781164.83.0.920550281583.issue10666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, readline.read_init_file() works with libedit too (provided that the config file uses libedit-style format), so you can remove the branch from your code.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Sat May  7 17:18:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:18:29 +0000
Subject: [issue10663] configure shouldn't set a default OPT
In-Reply-To: <1291922731.34.0.0931517118305.issue10663@psf.upfronthosting.co.za>
Message-ID: <1304781509.39.0.149436523872.issue10663@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sounds reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10663>
_______________________________________

From report at bugs.python.org  Sat May  7 17:25:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:25:55 +0000
Subject: [issue10581] Review and document string format accepted in numeric
	data type constructors
In-Reply-To: <1291053358.57.0.165550567454.issue10581@psf.upfronthosting.co.za>
Message-ID: <1304781955.89.0.4988257693.issue10581@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I may be in minority, but I find it convenient to use int(), float()
> etc. for data validation.
A number of libraries agree: argparse, HTML form handling libs,?etc.

> I may be too strict, but I don't think anyone would want to see
> columns with a mix of Bengali and Devanagari numerals. [...]
> On the other hand there is certain convenience in promiscuous
> parsers, but this is not an expectation that I have from int() and
> friends. [...] There are pros and cons in any approach.
Indeed, tough question.  On one hand, I tend to agree that mixing Hindi/Arab numerals with Bengali does not make sense; on the other hand, rejecting it means that the int code does know about Unicode, which you argued against.

>[MAL]
>> The codecs, Unicode methods and other Unicode support features
>> happily work with all kinds of languages, mixed or not, without any
>> such specification.
> In my view int() and friends are only marginally related to Unicode
> and Unicode methods design is not directly relevant to their behavior.
I think I agree.  It?s perfectly fine that Unicode support features don?t care about the type of the characters but just encode and decode; however, int has a validation step.  It rejects numerals that don?t make sense with the given base for example, so rejecting nonsensical sequences of Unicode numerals makes sense IMO.

What do the other languages that are able to convert from Unicode numerals to integer objects?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10581>
_______________________________________

From report at bugs.python.org  Sat May  7 17:27:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:27:49 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1304782069.08.0.347733839163.issue9923@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +No unit test for mailcap module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Sat May  7 17:29:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:29:21 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1304782161.4.0.584377372536.issue9923@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, is there a real use case that lead you to open this report, or is it just theoretical?  I?m not even sure mailcap is used on non-UNIX (and even there, I think it?s not used by recent tools).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Sat May  7 17:29:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 15:29:27 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <E1QIjRc-00031t-AM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6fa20e360e5e by Ezio Melotti in branch '2.7':
#12017: Fix segfault in json.loads() while decoding highly-nested objects using the C accelerations.
http://hg.python.org/cpython/rev/6fa20e360e5e

New changeset 61164d09337e by Ezio Melotti in branch '3.1':
#12017: Fix segfault in json.loads() while decoding highly-nested objects using the C accelerations.
http://hg.python.org/cpython/rev/61164d09337e

New changeset db97968379dd by Ezio Melotti in branch '3.2':
#12017: merge with 3.1.
http://hg.python.org/cpython/rev/db97968379dd

New changeset 389620c9e609 by Ezio Melotti in branch 'default':
#12017: merge with 3.2.
http://hg.python.org/cpython/rev/389620c9e609

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12017>
_______________________________________

From report at bugs.python.org  Sat May  7 17:29:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:29:55 +0000
Subject: [issue9859] Add tests to verify API match of modules with 2
	implementations
In-Reply-To: <1284558397.04.0.990092096712.issue9859@psf.upfronthosting.co.za>
Message-ID: <1304782195.38.0.879523105557.issue9859@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +belopolsky, brett.cannon, eric.araujo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9859>
_______________________________________

From report at bugs.python.org  Sat May  7 17:30:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:30:39 +0000
Subject: [issue10964] Mac installer need not add things to /usr/local
In-Reply-To: <1295566233.42.0.612397787907.issue10964@psf.upfronthosting.co.za>
Message-ID: <1304782239.09.0.0643623430421.issue10964@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/issue10964>
_______________________________________

From report at bugs.python.org  Sat May  7 17:31:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 May 2011 15:31:35 +0000
Subject: [issue12017] Decoding a highly-nested object with json (_speedups
	enabled) causes segfault
In-Reply-To: <1304684757.27.0.182455462298.issue12017@psf.upfronthosting.co.za>
Message-ID: <1304782295.74.0.903397320319.issue12017@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks Ivan for the report and Alex for suggesting Py_EnterRecursiveCall!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12017>
_______________________________________

From report at bugs.python.org  Sat May  7 17:33:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 May 2011 15:33:30 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1304782410.0.0.375097861347.issue9516@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I haven't changed the CompileError handling though, that would change
> a test failure into a test error.
Ah, thanks for correcting my mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sat May  7 17:42:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 07 May 2011 15:42:43 +0000
Subject: [issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
In-Reply-To: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>
Message-ID: <1304782963.26.0.738971468316.issue12002@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This is a nasty one and mainly it's the reason why there are no tests for abort() method.
In FTP, ABOR command is supposed to be sent as OOB (out-of-band) "urgent" data and the dummy FTP server we're using for the funcional tests must handle this appopriately.

In practical terms this means that when the client calls self.sock.sendall(line, MSG_OOB) the server is supposed to call socket.recv(1024, MSG_OOB).
Since our server uses asyncore this becomes quite twisted to handle.
This can be avoided by setting SO_OOBINLINE which tells the server to handle the urgent data inline meaning that both plain and urgent data can be received with a normal sock.recv(1024) call.

The patch in attachment does this and also fixes FTP_TLS.abort() which is not able to accept the extra MSG_OOB flag argument.

There's a side note: on certain platforms SO_OOBINLINE has no effect, resulting in asyncore's handle_expt method being called, see:
http://code.google.com/p/pyftpdlib/source/browse/trunk/pyftpdlib/ftpserver.py#2064
I haven't handled this case in my patch because I'm not sure what platforms are broken.
I'd say we can commit this patch as-is, wait for the buildbots to turn red and then disable the test for those platforms afterwards.

----------
keywords: +patch
Added file: http://bugs.python.org/file21925/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12002>
_______________________________________

From report at bugs.python.org  Sat May  7 18:01:04 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 07 May 2011 16:01:04 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304784064.48.0.593957508029.issue12027@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I suggest rejecting. See 8ae88db7843c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 18:01:58 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 07 May 2011 16:01:58 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304784118.71.0.0519474761231.issue12027@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 18:08:14 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 May 2011 16:08:14 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304784494.59.0.231854824259.issue12027@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

(And subsequently cc10b010f40b.  I agree with Benjamin.)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 18:13:43 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 07 May 2011 16:13:43 +0000
Subject: [issue12022] improve special method lookup error message
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1304784823.57.0.373863989897.issue12022@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution: invalid -> 
status: closed -> open
title: 'transaction' module-as-context-manager thwarted by Python 2.7.1 -> improve special method lookup error message

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12022>
_______________________________________

From report at bugs.python.org  Sat May  7 18:51:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 16:51:58 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <E1QIkjU-0008KO-Sb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7c3a20b5943a by Ezio Melotti in branch '2.7':
#10169: Fix argument parsing in socket.sendto() to avoid error masking.
http://hg.python.org/cpython/rev/7c3a20b5943a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10169>
_______________________________________

From report at bugs.python.org  Sat May  7 18:51:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 16:51:58 +0000
Subject: [issue5421] Irritating error message by socket's sendto method
In-Reply-To: <1236248103.61.0.911918415156.issue5421@psf.upfronthosting.co.za>
Message-ID: <E1QIkjU-0008KO-SP@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9222c9d747c1 by Ezio Melotti in branch '3.1':
#5421: add tests.
http://hg.python.org/cpython/rev/9222c9d747c1

New changeset 4b3352b49483 by Ezio Melotti in branch '3.2':
#5421: merge with 3.1.
http://hg.python.org/cpython/rev/4b3352b49483

New changeset 20273f2195ba by Ezio Melotti in branch 'default':
#5421: merge with 3.2.
http://hg.python.org/cpython/rev/20273f2195ba

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5421>
_______________________________________

From report at bugs.python.org  Sat May  7 18:53:22 2011
From: report at bugs.python.org (Kasun Herath)
Date: Sat, 07 May 2011 16:53:22 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1304787202.94.0.265328351897.issue11882@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

david, I'm not much familiar with c. Still trying to figure out how to do it

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Sat May  7 18:53:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 16:53:51 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1304787231.13.0.224550990302.issue11743@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch, fixing a sporadic failure in test_spawn_close.

----------
Added file: http://bugs.python.org/file21926/mpconn2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11743>
_______________________________________

From report at bugs.python.org  Sat May  7 18:54:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 May 2011 16:54:44 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1304787284.55.0.366232585164.issue10169@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This turned out to be a duplicate of #5421 already fixed in 3.x, so I backported the patch and added the tests to 3.x too.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10169>
_______________________________________

From report at bugs.python.org  Sat May  7 18:55:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 May 2011 16:55:36 +0000
Subject: [issue5421] Irritating error message by socket's sendto method
In-Reply-To: <1236248103.61.0.911918415156.issue5421@psf.upfronthosting.co.za>
Message-ID: <1304787336.23.0.873321214157.issue5421@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I backported the patch to 2.7 in 7c3a20b5943a, and added tests to the 3.x branches.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5421>
_______________________________________

From report at bugs.python.org  Sat May  7 19:02:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 May 2011 17:02:18 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304787738.79.0.859639267322.issue11910@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attempting to fix import_fresh_module might be better.

----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sat May  7 19:19:48 2011
From: report at bugs.python.org (Daniel Holth)
Date: Sat, 07 May 2011 17:19:48 +0000
Subject: [issue12022] AttributeError should report the same details when
	raised by lookup_special() as when raised in the REPL
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1304788788.72.0.636738247663.issue12022@psf.upfronthosting.co.za>


Daniel Holth <dholth at fastmail.fm> added the comment:

Python should explain AttributeError in the same way when it's raised by the interpreter. The with: statement below should raise the second AttributeError, not the first.

import transaction
with transaction: pass
>>> AttributeError: __exit__

import sys
sys.__exit__
>>> AttributeError: 'module' object has no attribute '__exit__'

----------
title: improve special method lookup error message -> AttributeError should report the same details when raised by lookup_special() as when raised in the REPL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12022>
_______________________________________

From report at bugs.python.org  Sat May  7 19:20:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2011 17:20:28 +0000
Subject: [issue11963] Remove human verification from test suite (test_parser
	and test_subprocess)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1304788828.3.0.829009675693.issue11963@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My title suggestion was meant to say "Yes, if you are willing to expand the scope of this issue and do more work, go ahead' ;-).

I have not looked at help(test), but it should be complete if it is not.
I was referring to the test module doc 25.5. Someone decided recently that test.support 25.6 should be complete, for the benefit of developers (like me) even though subject to change. Hence the recent patch. That chapter should probably start with a notice that these are private interfaces, subject to change, for testing of Python.

I'd like to see at least a listing and brief description of other stuff I should know about, perhaps in a new 25.6.2 section. An alternative would be something in the developer docs. Looking at the listing of /test is a bit confusing. I have pretty much ignored everything other than test_x (and regrtest.py), assuming that they were data files used by particular tests. Hence I was surprised by script_helper.py as an annex to support.py. Are there others (that are not single-test specific)? (I know, this should become another issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11963>
_______________________________________

From report at bugs.python.org  Sat May  7 19:22:36 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Sat, 07 May 2011 17:22:36 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <1304788956.3.0.265060224619.issue11968@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Yes, the 'b' is a docs error.

I previously removed this in:

   http://hg.python.org/cpython-fullhistory/rev/2697326d4a77 

It appears to have been reverted during a merge, here:

   http://hg.python.org/cpython-fullhistory/rev/88d04f0143c7

My browser crashed trying to view that huge second revision, so I'm not sure if there were any other regressions therein.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11968>
_______________________________________

From report at bugs.python.org  Sat May  7 19:29:06 2011
From: report at bugs.python.org (Kasun Herath)
Date: Sat, 07 May 2011 17:29:06 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <1304789346.54.0.0740116748449.issue11927@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

I'm submitting another patch which includes a test in test_smtpnet. Would appreciate further feedback.

----------
Added file: http://bugs.python.org/file21927/smtp_default_port_with_smtpnet_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11927>
_______________________________________

From report at bugs.python.org  Sat May  7 19:33:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 May 2011 17:33:36 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304789616.0.0.378299192203.issue11910@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Are you sure those tests are C specific?  Please be careful about doing unnecessary complexification of this module's tests.

----------
assignee: ezio.melotti -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sat May  7 19:35:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 17:35:51 +0000
Subject: [issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
In-Reply-To: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>
Message-ID: <E1QIlPw-0002qb-Du@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 31220cd936d2 by Giampaolo Rodola' in branch '3.1':
#12002 - ftplib's abort() method raises TypeError
http://hg.python.org/cpython/rev/31220cd936d2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12002>
_______________________________________

From report at bugs.python.org  Sat May  7 19:39:43 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 07 May 2011 17:39:43 +0000
Subject: [issue12026] Support more of MSI api by exposing handles
In-Reply-To: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>
Message-ID: <1304789983.57.0.0249672341359.issue12026@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's the purpose of the patch? I.e. what can you do when you have the handle exposed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12026>
_______________________________________

From report at bugs.python.org  Sat May  7 19:42:20 2011
From: report at bugs.python.org (Daniel Holth)
Date: Sat, 07 May 2011 17:42:20 +0000
Subject: [issue12022] AttributeError should report the same details when
	raised by lookup_special() as when raised in the REPL
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1304790140.73.0.842175682249.issue12022@psf.upfronthosting.co.za>


Daniel Holth <dholth at fastmail.fm> added the comment:

Thank you Benjamin for following up on this issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12022>
_______________________________________

From report at bugs.python.org  Sat May  7 19:48:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 17:48:52 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <E1QIlcY-0003TM-Fo@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 20e9d3e49689 by Antoine Pitrou in branch '3.1':
Issue #11927: SMTP_SSL now uses port 465 by default as documented.  Patch by Kasun Herath.
http://hg.python.org/cpython/rev/20e9d3e49689

New changeset 209744660b92 by Antoine Pitrou in branch '3.2':
Merge: Issue #11927: SMTP_SSL now uses port 465 by default as documented.
http://hg.python.org/cpython/rev/209744660b92

New changeset e708a57de190 by Antoine Pitrou in branch 'default':
Merge: Issue #11927: SMTP_SSL now uses port 465 by default as documented.
http://hg.python.org/cpython/rev/e708a57de190

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11927>
_______________________________________

From report at bugs.python.org  Sat May  7 19:51:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 17:51:32 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304790692.3.0.902430406121.issue9205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, this patch seems fully debugged (under Windows and Linux). A couple of things come in addition, such as removing repeated polling in PipeConnection.poll() and _Popen.wait().

----------
Added file: http://bugs.python.org/file21928/sentinels3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Sat May  7 19:52:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 17:52:22 +0000
Subject: [issue11668] _multiprocessing.Connection.poll with timeout uses
	polling under Windows
In-Reply-To: <1301012856.06.0.501822966935.issue11668@psf.upfronthosting.co.za>
Message-ID: <1304790742.48.0.966414690009.issue11668@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have a full patch using overlapped I/O in issue9205 (sentinels3.patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11668>
_______________________________________

From report at bugs.python.org  Sat May  7 19:59:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 17:59:39 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <E1QIlmz-00047c-Jo@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bcf04ced5ef1 by Antoine Pitrou in branch '2.7':
Issue #11927: SMTP_SSL now uses port 465 by default as documented.  Patch by Kasun Herath.
http://hg.python.org/cpython/rev/bcf04ced5ef1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11927>
_______________________________________

From report at bugs.python.org  Sat May  7 20:01:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 18:01:36 +0000
Subject: [issue11927] SMTP_SSL doesn't use port 465 by default
In-Reply-To: <1303836501.95.0.366662026013.issue11927@psf.upfronthosting.co.za>
Message-ID: <1304791296.49.0.0312157734598.issue11927@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch was committed in dev and maintenance branches. Thank you!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11927>
_______________________________________

From report at bugs.python.org  Sat May  7 20:05:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 May 2011 18:05:43 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304791543.92.0.147359913684.issue11910@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If they are not C specific they should be moved to the base class (TestHeap).  TestHeapC and TestHeapPython should contain only tests specific to the C and Python versions respectively.

The goal here is to make sure that they are run once with the Python version, and again with the C version -- but only if the C version is available.
Currently, if _heapq is missing, the C tests (i.e. TestHeapC) are run anyway using the Python module, when instead they should be skipped.

c_heapq = import_fresh_module('heapq', fresh=['_heapq']) should be fixed to try to import _heapq and return None if the import fails, so that a @skipUnless(c_heapq, 'test requires the _heapq module') decorator can be added to TestHeapC.
See also http://www.python.org/dev/peps/pep-0399/

This can be fixed in 2.7 first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sat May  7 21:33:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 May 2011 19:33:03 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304796783.42.0.0420970407038.issue12027@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Raymond: What do you think? Do you prefer simple or faster code?

I think that the speed of "import this" do matter!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 21:38:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 19:38:07 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1304762460.2.0.823890484797.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304797083.3526.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> pending_signals-3.patch:
>  - don't check for pending signals in sigwait()
>  - pthread_kill() doc: it is not a good idea to say that pthread_kill() with signum=0 can be used to check if a thread identifier is valid => such test does crash (SIGSEGV) on my Linux box. I changed the doc to say that it can be used to check if a thread is still running (which is different).
>  - add a dedicated test for sigpending()
>  - doc: explain how to get a thread identifier for pthread_kill()
>  - don't compile pthread_kill() without threads: you cannot get a valid thread identifier without the _thread module
> 
> I think that the patch is ready to be commited. Anyone for a last
> review? (antoine, neologix?)

It looks good to me.
It's very nice to have all these extra functions :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sat May  7 21:47:41 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 May 2011 19:47:41 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304797661.15.0.340865556667.issue10666@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

??ric, was your comment in msg135467 intended for another issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Sat May  7 21:51:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 May 2011 19:51:18 +0000
Subject: [issue12027] Optimize import this (patch to make it 10x faster)
In-Reply-To: <1304761974.72.0.959452098494.issue12027@psf.upfronthosting.co.za>
Message-ID: <1304797878.0.0.172776081853.issue12027@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Move on, nothing to see here ;-)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12027>
_______________________________________

From report at bugs.python.org  Sat May  7 21:56:39 2011
From: report at bugs.python.org (Peter Eisentraut)
Date: Sat, 07 May 2011 19:56:39 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304798199.38.0.149077930034.issue12012@psf.upfronthosting.co.za>


Changes by Peter Eisentraut <peter_e at gmx.net>:


----------
nosy: +petere

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Sat May  7 22:55:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2011 20:55:18 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304801718.91.0.267362502877.issue9205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hum, I get a strange skip on a XP buildbot:

[224/354] test_multiprocessing
test_multiprocessing skipped -- DLL load failed: The specified procedure could not be found.

Yet _multiprocessing was compiled fine... Does anyone know what it means?

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%20custom/builds/5/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Sat May  7 23:30:41 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 May 2011 21:30:41 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304803841.74.0.356864180446.issue11910@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Some of the tests were incorrectly marked as being C specific.  I've fixed that on the 2.7 branch.  Re-assigning back to Ezio.

Overall, I don't think the current approach to testing both paths is elegant.  Is there some alternative approach to running suites in two different context without adding .module indirections and multiple subclasses throughout the code?

----------
assignee: rhettinger -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sat May  7 23:34:43 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 07 May 2011 21:34:43 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1304804083.57.0.789460312645.issue11347@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Removed file: http://bugs.python.org/file20939/libpython3.so.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Sat May  7 23:39:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 May 2011 21:39:46 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304804386.68.0.0328005531323.issue11910@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm imagining a cleaner testing style, like this:

class TestHeap(unittest.TestCase):

    def test_nsmallest(self):
        self.assertEqual(heapq.nsmallest(3, range(10)), [0,1,2])
        ...

    @test_support.requires('_heapq')
    def test_comparison_operator(self):
        ...

def test_main(verbose=None):
    test_classes = [TestHeapPython, TestErrorHandling]
    test_support.run_unittest(*test_classes)

    test_support.reload('heapq', hiding='_heapq')
    test_support.run_unittest(*test_classes)

Ideally, we should be able to hide individual methods and be able to mark entire test classes with decorators for required features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sat May  7 23:43:44 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 07 May 2011 21:43:44 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304804624.01.0.325988568291.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

It seems to me that the point of using readinto() is to avoid double-buffering (and the extra alloc/free that comes with read()). The slowness of using a small buffer size seems like only a natural and expected consequence. 

The trade-off of accommodating a small buffer size (by buffering behind the scenes anyways) would likely slow the more common cases which use a decent buffer size. I am wondering if an effort to accommodate both uses would be appropriate. Possibly by not double-buffering if readinto(b): len(b) > buffer_size/2 (arbitrary but seems feasible), and copying directly as the patch does now. Otherwise, fill the buffer up for subsequent reads and copy len(b) to user buffer. There is probably a good equilibrium for when it makes more/less sense to bypass the internal buffer.

Changing _bufferedreader_read_generic() would require some of the other helpers to be changed as well but it may be the way to go.

Let me know what you think of the above. I will experiment a bit. Unfortunately I am a bit busy this weekend but cannot wait to work on this again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sat May  7 23:46:21 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 07 May 2011 21:46:21 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1304804781.44.0.856148154396.issue11347@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm attaching improved patch, which adds detection of -Wl,--no-as-needed flag. This issue should be release blocker for Python 3.2.1.

----------
Added file: http://bugs.python.org/file21929/libpython3.so.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Sat May  7 23:48:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 May 2011 21:48:10 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304804890.22.0.0270933108196.issue11910@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks (for the record the changeset is a8b82c283524).

> Overall, I don't think the current approach to testing both paths
> is elegant.
That's the most elegant way we have now.  If all the Python tests pass for the C version too, a base class could be avoided and the C tests could inherit directly from the Python ones (possibly adding additional C-specific tests).  I actually prefer this way because the Python tests should be an invariant of all the Python implementations and additional tests for the accelerations can be created from them with appropriate skip decorators, e.g.:
class PythonFooTests(TestCase):
    ...

@skipUnless(is_cypthon and c_foo)
class CFooTests(PythonTest):
   ...

@skipUnless(is_jython and j_foo)
class JFooTests(PythonTest):
   ...

This also avoid to list the tests explicitly at the end to exclude the base class (e.g. currently we have to exclude TestHeap, and list TestHeapC and TestHeapPy).


We could come up with some smart class decorator that runs a set of tests with and without accelerations, but it will make more difficult to add tests specific to the C or Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sun May  8 00:20:04 2011
From: report at bugs.python.org (Alex Lai)
Date: Sat, 07 May 2011 22:20:04 +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: <1304806804.33.0.844414930694.issue12013@psf.upfronthosting.co.za>


Alex Lai <alex_lai at scotiacapital.com> added the comment:

The test fialed on my workstation while successul on another server. Both server has the same Pyton installation but different libc and libm version. I plan to reinstall the OS(solaris 10 pre-release) on my workstation next week and see how it goes.

Regards,

Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Sun May  8 01:48:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2011 23:48:30 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QIrEb-0002Ee-6k@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1d8a57deddc4 by Victor Stinner in branch 'default':
Issue #8407: Add pthread_kill(), sigpending() and sigwait() functions to the
http://hg.python.org/cpython/rev/1d8a57deddc4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sun May  8 01:50:00 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 07 May 2011 23:50:00 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304812200.66.0.113005397631.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

FWIW, It seems Java does something similar. They write directly into caller's buffer if outstanding bytes needed (after emptying internal buffer) is greater than internal buffer len.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sun May  8 02:03:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2011 00:03:48 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QIrTL-00030I-Az@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f8c49a930015 by Victor Stinner in branch 'default':
Issue #8407: The signal handler writes the signal number as a single byte
http://hg.python.org/cpython/rev/f8c49a930015

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sun May  8 02:10:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2011 00:10:51 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QIraC-0003Qc-W8@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e3cb2c99a5a9 by Victor Stinner in branch 'default':
Issue #8407: Remove debug code from test_signal
http://hg.python.org/cpython/rev/e3cb2c99a5a9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sun May  8 02:14:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 00:14:51 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1304801718.91.0.267362502877.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304813688.3526.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hum, I get a strange skip on a XP buildbot:
> 
> [224/354] test_multiprocessing
> test_multiprocessing skipped -- DLL load failed: The specified
> procedure could not be found.
> 
> Yet _multiprocessing was compiled fine... Does anyone know what it
> means?

Ok, the culprit is CancelIoEx(), which is only supported under Vista and
later (but, strangely enough, compiles fine under XP).
I need to use CancelIo() instead, which will lead me to change the
implementation strategy slightly (the fact that CancelIo() is
thread-specific makes it unsuitable for a tp_dealloc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Sun May  8 02:19:34 2011
From: report at bugs.python.org (John O'Connor)
Date: Sun, 08 May 2011 00:19:34 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304813974.4.0.947408938058.issue9971@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


Removed file: http://bugs.python.org/file21899/buffered_readinto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sun May  8 02:19:47 2011
From: report at bugs.python.org (John O'Connor)
Date: Sun, 08 May 2011 00:19:47 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304813987.07.0.430625464771.issue9971@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


Removed file: http://bugs.python.org/file21900/buffered_readinto2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sun May  8 02:31:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 00:31:33 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304814693.54.0.274531660961.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update the signalfd patch (version 4) against the default branch. Specify the minimum Linux version in signalfd() doc. The patch still lacks a structure to parse the bytes written into the file (see msg135438 for a ctypes example): a struct sequence should be fine.

----------
Added file: http://bugs.python.org/file21930/signalfd-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sun May  8 02:52:46 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 May 2011 00:52:46 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1304815966.38.0.678444867015.issue11164@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm attaching the patch, which fixes this issue. It would be nice if the patch was applied before releases of Python 3.1.4 and 3.2.1.

----------
keywords: +patch
Added file: http://bugs.python.org/file21931/python-3-remove_pyxml_support.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Sun May  8 03:19:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 May 2011 01:19:37 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1304817577.7.0.207997839847.issue11164@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/issue11164>
_______________________________________

From report at bugs.python.org  Sun May  8 04:14:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 May 2011 02:14:57 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304820897.76.0.874177064591.issue11910@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Attaching a rough draft of a way to simplify dual path testing.  The idea is that the suite shouldn't have to be rewritten with self.module.heapify(...) references throughout.  Instead, tests are written normally and the only thing that changes in the context that they are executed in (not much different that if we simply commented out the import of c accelerator code).

Several things need work:
1) There needs to be a way to run only one block of tests if _heapqmodule isn't built.

2) the unittest.skipUnless decorator doesn't work (it does a static computation during compilation rather than a dynamic test during execution).  The attached rough draft code works around this by putting the skip logic inside the test.  This should be done more cleanly.

3) It would be great if there were a way to test unittest's test runner which version is being tested so that if there is a failure, it's obvious which context is being tested.

The patch is a proof-of-concept that would need polishing before becoming the preferred way of doing multiple path testing.

----------
Added file: http://bugs.python.org/file21932/new_heapq_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sun May  8 07:00:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 May 2011 05:00:39 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1304830839.27.0.843352697876.issue11347@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Martin?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Sun May  8 07:00:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 May 2011 05:00:55 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1304830855.92.0.449365417281.issue11347@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Sun May  8 07:02:45 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 May 2011 05:02:45 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1304830965.42.0.546165742673.issue11164@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

In MinidomTest.tearDown, the majority of the code seems to be for the stdlib version, yet you remove the whole method. Can you elaborate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Sun May  8 07:56:08 2011
From: report at bugs.python.org (torstenb)
Date: Sun, 08 May 2011 05:56:08 +0000
Subject: [issue11375] urllib2 over SOCKS doesn't use proxy for DNS
In-Reply-To: <1299077508.41.0.756366246736.issue11375@psf.upfronthosting.co.za>
Message-ID: <1304834168.29.0.926738286464.issue11375@psf.upfronthosting.co.za>


Changes by torstenb <torstenb at vmunix.org>:


----------
nosy: +torstenb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11375>
_______________________________________

From report at bugs.python.org  Sun May  8 08:33:55 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 08 May 2011 06:33:55 +0000
Subject: [issue12022] AttributeError should report the same details when
	raised by lookup_special() as when raised in the REPL
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1304836435.67.0.251609239791.issue12022@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/issue12022>
_______________________________________

From report at bugs.python.org  Sun May  8 10:28:51 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sun, 08 May 2011 08:28:51 +0000
Subject: [issue12026] Support more of MSI api by exposing handles
In-Reply-To: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>
Message-ID: <1304843331.65.0.400246064682.issue12026@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

You can pass it to any function in the MSI SDK through ctypes.

e.g. 

    def ReadStream(record, field):
        buf = (ctypes.c_char * 2048)()
        orig_size = ctypes.sizeof(buf)
        status = 0
        res = []
        while status == 0:
            size = ctypes.c_long(ctypes.sizeof(buf))
            status = msidll.MsiRecordReadStream(
                record.hanlde, field, ctypes.byref(buf), ctypes.byref(size))
            res.append(buf.raw)
            if size.value != orig_size:
                break
        data = "".join(res)
        return data


or any of the other functions not currently implemented in _msi.c
Some of the other important ones (to me at least) are:
 - MsiDatabaseGetPrimaryKeys
 - MsiDatabaseExport
 - MsiDatabaseImport

If the whole MSI SDK is wrapped - then exposing the handles would have no use :).

The alternative I have so far is to re-write _msi.c using ctypes (already done), but I thought it would be better if not all of _msi.c had to be re-implemented.

One alternative patch is to include those extra functions in _msi.c (though I am not sure I have the C skills to achieve that easily - and it may still miss functionality, and it may have even less chance of being accepted)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12026>
_______________________________________

From report at bugs.python.org  Sun May  8 10:33:56 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 08 May 2011 08:33:56 +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: <1304843636.1.0.337031197286.issue11877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Steffen, I don't understand your comment about "auto". Declaring variables as "auto" is not necessary in C code and not used anywhere else in Python's source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sun May  8 10:53:43 2011
From: report at bugs.python.org (andrew cooke)
Date: Sun, 08 May 2011 08:53:43 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>


New submission from andrew cooke <andrew at acooke.org>:

Hi,

In general, registering a class with an ABC is equivalent to making it a subclass (isinstance and issubclass are patched through ABCMeta).  However, this does not work for exceptions (see example below, where exception is not caught).

This doesn't seem terribly surprising to me - I imagine that checking would slow down exception handling - but I couldn't find any documentation (and posting on c.l.p didn't turn up anything either).

So I thought I would raise it here - perhaps there is a possible fix (my obscure use case is that I have a backtracking search; backtracking occurs when a certain exception is encountered; making that exception an ABC and allowing existing exceptions to be registered with it allows the search to work with existing code without a wrapper that catches and translates exceptions that should trigger a backtrack).  Or perhaps the docs could be extended.  Or perhaps I've misunderstood something...

Cheers,
Andrew

Python 3.2 (r32:88445, Feb 27 2011, 13:00:05) 
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from abc import ABCMeta
>>> class RootException(Exception,metaclass=ABCMeta): pass
... 
>>> class MyException(Exception): pass
... 
>>> RootException.register(MyException)
>>> try:
...     raise MyException
... except RootException:
...     print('caught')
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
__main__.MyException

----------
components: Interpreter Core
messages: 135521
nosy: acooke
priority: normal
severity: normal
status: open
title: ABC registration of Exceptions
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Sun May  8 11:02:07 2011
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 08 May 2011 09:02:07 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1304845327.95.0.826394521069.issue12029@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/issue12029>
_______________________________________

From report at bugs.python.org  Sun May  8 11:32:58 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 08 May 2011 09:32:58 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1304847178.15.0.068159656406.issue12029@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/issue12029>
_______________________________________

From report at bugs.python.org  Sun May  8 15:28:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 13:28:24 +0000
Subject: [issue11375] urllib2 over SOCKS doesn't use proxy for DNS
In-Reply-To: <1299077508.41.0.756366246736.issue11375@psf.upfronthosting.co.za>
Message-ID: <1304861304.56.0.201936852114.issue11375@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like a bug in the third-party "socks" module rather than in urllib. You should report it there.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11375>
_______________________________________

From report at bugs.python.org  Sun May  8 16:18:01 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 May 2011 14:18:01 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1304864281.45.0.48440040412.issue11164@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I have verified that xml.dom.minidom.Node from neither stdlib (at least 2.6, 2.7, 3.1, 3.2 and 3.3) nor PyXML 0.8.4 has 'allnodes' attribute.

If you install PyXML 0.8.4 for Python 2.7 and change 'pass' in MinidomTest.tearDown() into 'raise', then the following commands will print the same exceptions in MinidomTest.tearDown():

# With PyXML
# "FAILED (failures=8, errors=111)"
$ python2.7 -m test.test_minidom

# Without PyXML
# "FAILED (errors=110)"
$ python2.7 -S -m test.test_minidom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Sun May  8 16:27:10 2011
From: report at bugs.python.org (Ralph Corderoy)
Date: Sun, 08 May 2011 14:27:10 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1304864830.64.0.333911175024.issue10713@psf.upfronthosting.co.za>


Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk> added the comment:

Examining the source of Ubuntu's python2.6 2.6.6-5ubuntu1 package
suggests beyond the limits of the string is considered \W, like Perl.

    Modules/_sre.c:
       336  LOCAL(int)
       337  SRE_AT(SRE_STATE* state, SRE_CHAR* ptr, SRE_CODE at)
       338  {
       339      /* check if pointer is at given position */
       340
       341      Py_ssize_t thisp, thatp;
       ...
       365      case SRE_AT_BOUNDARY:
       366          if (state->beginning == state->end)
       367              return 0;
       368          thatp = ((void*) ptr > state->beginning) ?
       369              SRE_IS_WORD((int) ptr[-1]) : 0;
       370          thisp = ((void*) ptr < state->end) ?
       371              SRE_IS_WORD((int) ptr[0]) : 0;
       372          return thisp != thatp;

SRE_IS_WORD() returns 16 for the 63 \w characters, 0 otherwise.

This is born out by tests.

Note, 366 above confirms it's never true for an empty string.  The
documentation states that \B "is just the opposite of \b" yet
re.match(r'\b', '') returns None and so does \B so \B isn't the opposite
of \b in all cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Sun May  8 16:32:59 2011
From: report at bugs.python.org (Ralph Corderoy)
Date: Sun, 08 May 2011 14:32:59 +0000
Subject: [issue12030] Roundup Refused Update with No text/plain
In-Reply-To: <1304865179.02.0.563101474809.issue12030@psf.upfronthosting.co.za>
Message-ID: <1304865179.02.0.563101474809.issue12030@psf.upfronthosting.co.za>


New submission from Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:

I tried to reply to the email I was sent when eric.araujo added a comment to #10713.  The email I sent was plain text but wasn't a MIME email.  It was rejected, "Failed issue tracker submission", "Roundup requires the submission to be plain text. The message parser could
not find a text/plain part to use."

I understand why it looks for plain/text parts of a MIME email, but shouldn't it be happy with a non-MIME email that by definition is plain text and has only one part?  I've attached the rejected email.

----------
components: None
files: nonmime.txt
messages: 135525
nosy: ralph.corderoy
priority: normal
severity: normal
status: open
title: Roundup Refused Update with No text/plain
versions: 3rd party
Added file: http://bugs.python.org/file21933/nonmime.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12030>
_______________________________________

From report at bugs.python.org  Sun May  8 16:36:14 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 08 May 2011 14:36:14 +0000
Subject: [issue12030] Roundup Refused Update with No text/plain
In-Reply-To: <1304865179.02.0.563101474809.issue12030@psf.upfronthosting.co.za>
Message-ID: <1304865374.92.0.845159288256.issue12030@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This belongs on http://psf.upfronthosting.co.za/roundup/meta/.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12030>
_______________________________________

From report at bugs.python.org  Sun May  8 16:37:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 May 2011 14:37:51 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1304865471.41.0.421435819372.issue11164@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I suggest to remove dead code in test_minidom in Python 2.7 to avoid confusion.

----------
Added file: http://bugs.python.org/file21934/python-2.7-test_minidom-remove_dead_code.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Sun May  8 17:49:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 15:49:25 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1304804624.01.0.325988568291.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304869759.3541.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The trade-off of accommodating a small buffer size (by buffering
> behind the scenes anyways) would likely slow the more common cases
> which use a decent buffer size. I am wondering if an effort to
> accommodate both uses would be appropriate. Possibly by not
> double-buffering if readinto(b): len(b) > buffer_size/2 (arbitrary but
> seems feasible), and copying directly as the patch does now.
> Otherwise, fill the buffer up for subsequent reads and copy len(b) to
> user buffer. There is probably a good equilibrium for when it makes
> more/less sense to bypass the internal buffer.

Yes, it sounds reasonable. I think the best thing to do is to experiment
and run some measurements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Sun May  8 18:06:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 16:06:17 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1304870777.4.0.793261694739.issue8809@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you, the patch looks good. A simple test could probably be added to test_smtpnet, along the lines of the existing tests, do you want to tackle that?

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Sun May  8 18:19:01 2011
From: report at bugs.python.org (marko kreen)
Date: Sun, 08 May 2011 16:19:01 +0000
Subject: [issue12031] subprocess module does not accept file twice
In-Reply-To: <1304871541.62.0.951242966353.issue12031@psf.upfronthosting.co.za>
Message-ID: <1304871541.62.0.951242966353.issue12031@psf.upfronthosting.co.za>


New submission from marko kreen <markokr at gmail.com>:

I want to pass /dev/null as stdin and stderr.

This works from python 2.4 .. 3.2a3

It fails in final 3.2 with 'Bad file descriptor':

Traceback (most recent call last):
  File "test.py", line 11, in <module>
    Popen(['cat', 'file.txt'], stdout = PIPE, stdin = _in, stderr = _err)
  File "/opt/apps/python320/lib/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/opt/apps/python320/lib/python3.2/subprocess.py", line 1330, in _execute_child
    raise child_exception_type(errno_num, err_msg)
OSError: [Errno 9] Bad file descriptor

----------
components: Library (Lib)
files: test.py
messages: 135530
nosy: zmk
priority: normal
severity: normal
status: open
title: subprocess module does not accept file twice
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file21935/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12031>
_______________________________________

From report at bugs.python.org  Sun May  8 18:55:31 2011
From: report at bugs.python.org (Stephen Ferg)
Date: Sun, 08 May 2011 16:55:31 +0000
Subject: [issue12032] Tools/Scripts/crlv.py needs updating for python 3+
In-Reply-To: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>
Message-ID: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>


New submission from Stephen Ferg <zuulixia at ferg.org>:

I think this is a consequence of the new Unicode support in Python 3+

Here is code copied from C:\Python32\Tools\Scripts\crlf.py (on windows)
==================================================================
    for filename in os.listdir("."):
        if os.path.isdir(filename):
            print(filename, "Directory!")
            continue
        data = open(filename, "rb").read()
        if '\0' in data:
            print(filename, "Binary!")
            continue
        newdata = data.replace("\r\n", "\n")
        if newdata != data:
            print(filename)

===================================================================

When run, it produces this (run under the PyCharm debugger)

===================================================================
C:\Python32\python.exe C:/pydev/zob/zobtest.py
Traceback (most recent call last):
  File "C:/pydev/zob/zobtest.py", line 134, in <module>
    x() 
  File "C:/pydev/zob/zobtest.py", line 126, in x
    if '\0' in data:
TypeError: Type str doesn't support the buffer API

Process finished with exit code 1
===================================================================

Removing the test for "\0" produces this:
===================================================================
C:\Python32\python.exe C:/pydev/zob/zobtest.py
Traceback (most recent call last):
  File "C:/pydev/zob/zobtest.py", line 131, in <module>
    x()  
  File "C:/pydev/zob/zobtest.py", line 126, in x
    newdata = data.replace("\r\n", "\n")
TypeError: expected an object with the buffer interface

Process finished with exit code 1
===================================================================

----------
components: Demos and Tools
messages: 135531
nosy: stephen_ferg
priority: normal
severity: normal
status: open
title: Tools/Scripts/crlv.py needs updating for python 3+
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12032>
_______________________________________

From report at bugs.python.org  Sun May  8 19:09:35 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 08 May 2011 17:09:35 +0000
Subject: [issue12031] subprocess module does not accept file twice
In-Reply-To: <1304871541.62.0.951242966353.issue12031@psf.upfronthosting.co.za>
Message-ID: <1304874575.27.0.0296290774295.issue12031@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

I can reproduce this on 3.2 final but not on the tip of the 3.2 branch so it seems to have been fixed.

----------
nosy: +catalin.iacob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12031>
_______________________________________

From report at bugs.python.org  Sun May  8 19:17:04 2011
From: report at bugs.python.org (Alex Lai)
Date: Sun, 08 May 2011 17:17:04 +0000
Subject: [issue12033] AttributeError: 'module' object has no attribute 'scipy'
In-Reply-To: <1304875024.3.0.0342220610615.issue12033@psf.upfronthosting.co.za>
Message-ID: <1304875024.3.0.0342220610615.issue12033@psf.upfronthosting.co.za>


New submission from Alex Lai <alex_lai at scotiacapital.com>:

Hi experts,
  I'm new to Python. I've just successfully compiled and installed NumPy and SciPy. When I run the tests, Numpy shows no issues:

# python3 -c "import numpy; numpy.test()"
Running unit tests for numpy
NumPy version 1.5.1
NumPy is installed in /usr/local/lib/python3.1/site-packages/numpy
Python version 3.1.2 (r312:79147, Mar 23 2010, 02:42:06) [GCC 3.4.6]
nose version 1.0.0

----------------------------------------------------------------------
Ran 0 tests in 0.027s


  However, test for Scipy gave the following error:

# python3 -c "import numpy; import scipy; numpy.scipy()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'scipy'

  Any idea what might be missing here?

Thanks in advance,

Alex

----------
components: Tests
messages: 135533
nosy: alex_lai
priority: normal
severity: normal
status: open
title: AttributeError: 'module' object has no attribute 'scipy'
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12033>
_______________________________________

From report at bugs.python.org  Sun May  8 19:18:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 May 2011 17:18:05 +0000
Subject: [issue12031] subprocess module does not accept file twice
In-Reply-To: <1304871541.62.0.951242966353.issue12031@psf.upfronthosting.co.za>
Message-ID: <1304875085.54.0.835079850289.issue12031@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's a duplicate of issue #11432: http://bugs.python.org/issue11432

----------
nosy: +neologix
resolution:  -> out of date
status: open -> closed
superseder:  -> webbrowser.open on unix fails.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12031>
_______________________________________

From report at bugs.python.org  Sun May  8 19:18:45 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 08 May 2011 17:18:45 +0000
Subject: [issue12033] AttributeError: 'module' object has no attribute 'scipy'
In-Reply-To: <1304875024.3.0.0342220610615.issue12033@psf.upfronthosting.co.za>
Message-ID: <1304875125.04.0.847923288006.issue12033@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

This bug tracker is for filing bugs in Python itself, for support with 3rd party libraries you should try their mailing lists or IRC channels.

----------
nosy: +alex
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12033>
_______________________________________

From report at bugs.python.org  Sun May  8 19:21:05 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 08 May 2011 17:21:05 +0000
Subject: [issue10581] Review and document string format accepted in numeric
	data type constructors
In-Reply-To: <1304781955.89.0.4988257693.issue10581@psf.upfronthosting.co.za>
Message-ID: <BANLkTimGYi=P9fzBgU=uS-juXZ824Ei4bg@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 7, 2011 at 11:25 AM, ?ric Araujo <report at bugs.python.org> wrote:
> .. On one hand, I tend to agree that mixing Hindi/Arab numerals with Bengali does not make sense;
> on the other hand, rejecting it means that the int code does know about Unicode, which you argued
> against.

In order to flag use of mixed scripts in numerals, the code does not
require access to any additional unicode data.  Since Unicode 6.0.0,
programmers can rely on the following stability promise:

"""
Characters with the property value Numeric_Type=de (Decimal) only
occur in contiguous ranges of 10 characters, with ascending numeric
values from 0 to 9 (Numeric_Value=0..9).
"""  -- http://www.unicode.org/policies/stability_policy.html

Therefore, the validation code can simply check that for all digits in
the number, ord(d) - unicodedata.numeric(d) is the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10581>
_______________________________________

From report at bugs.python.org  Sun May  8 20:36:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 May 2011 18:36:47 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304879807.97.0.936164817888.issue11910@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a patch that fixes import_fresh_module to return None when _heapq is missing and skips the C test when _heapq is missing.

I also added an additional test to verify that the functions in c_heapq are really C functions and the ones in py_heapq are really Python functions.

----------
Added file: http://bugs.python.org/file21936/issue11910.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sun May  8 20:46:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 May 2011 18:46:51 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304880411.87.0.464187779505.issue11910@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

BTW, if the fix for import_fresh_module is OK, it should be committed separately.
The tests I added to check that the C functions are really C functions could stay in test_heapq or they could be moved to test_test_support (see #11049), possibly together with tests for other modules like json/_json.  These tests are making sure that import_fresh_module works correctly but on the other hand they are also a precondition for a meaningful run of the following heapq tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Sun May  8 20:52:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 May 2011 18:52:00 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304880720.93.0.585842230031.issue11910@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/issue11910>
_______________________________________

From report at bugs.python.org  Sun May  8 21:50:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 19:50:44 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304884244.41.0.634670857395.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset f8c49a930015 by Victor Stinner in branch 'default':
> Issue #8407: The signal handler writes the signal number as a single byte

Wakeup test using two pending signals fails on FreeBSD 6.4 buildbot:

======================================================================
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 266, 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 232, in check_signum
    self.assertSequenceEqual(raised, signals)
AssertionError: Sequences differ: (14,) != (30, 14)

Wakeup file only contains SIGALRM, not (SIGUSR1, SIGALRM), whereas SIGUSR1 is raised before SIGALRM.

Code of the test:
                                                                                
    def check_signum(self, *signals):                                           
        data = os.read(self.read, len(signals)+1)                               
        raised = struct.unpack('%uB' % len(data), data)                         
        self.assertSequenceEqual(raised, signals)

    def test_signum(self):                                                      
        old_handler = signal.signal(signal.SIGUSR1, lambda x,y:None)            
        self.addCleanup(signal.signal, signal.SIGUSR1, old_handler)             
        os.kill(os.getpid(), signal.SIGUSR1)                                    
        os.kill(os.getpid(), signal.SIGALRM)                                    
        self.check_signum(signal.SIGUSR1, signal.SIGALRM)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Sun May  8 22:00:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 20:00:06 +0000
Subject: [issue12034] check_GetFinalPathNameByHandle() suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The code for check_GetFinalPathNameByHandle() goes like this:


static int has_GetFinalPathNameByHandle = 0;
[...]

static int
check_GetFinalPathNameByHandle()
{
    HINSTANCE hKernel32;
    /* only recheck */
    if (!has_GetFinalPathNameByHandle)
    {
        [...]
        has_GetFinalPathNameByHandle = Py_GetFinalPathNameByHandleA &&
                                       Py_GetFinalPathNameByHandleW;
    }
    return has_GetFinalPathNameByHandle;
}


It means that if the computed value is 0 (system doesn't have GetFinalPathNameByHandle*), the value will be re-computed each time the function is called.  has_GetFinalPathNameByHandle should probably be tri-state instead (0, 1, unknown).

----------
components: Extension Modules
keywords: easy
messages: 135540
nosy: brian.curtin, pitrou
priority: low
severity: normal
status: open
title: check_GetFinalPathNameByHandle() suboptimal
type: performance
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12034>
_______________________________________

From report at bugs.python.org  Sun May  8 23:12:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 21:12:08 +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: <1304889128.09.0.55214961657.issue6721@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file21875/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun May  8 23:13:12 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 08 May 2011 21:13:12 +0000
Subject: [issue11983] Inconsistent hash and comparison for code objects
In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za>
Message-ID: <1304889192.65.0.685234690563.issue11983@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

It appears that

* co_name was added to hash and cmp in this check-in by Guido:
http://hg.python.org/cpython-fullhistory/diff/525b2358721e/Python/compile.c
I think the reason was to preserve function name when defining multiple functions with the same code in one function or module. (By default function gets it's name from code, but only one code object will be preserved, since all constants in a function are stored in a dict during compilation).

* co_firstlineno was added to cmp (but not hash) in this check-in by Brett:
http://hg.python.org/cpython-fullhistory/rev/8127a55a57cb
In an attempt to fix this bug: http://www.mail-archive.com/python-bugs-list at python.org/msg02440.html
It doesn't actually fix the bug and makes hash inconsistent with cmp. I'm not convinced that the bug is valid -- why would you care if identical lambdas share or not share the code?


Both changes seem come from a tension between code object's original intention to compare "functionally equivalent" codes equal and side-effects of constants de-duplication in a function (loss of function name, broken breakpoints and line numbers in a debugger).
I can think of 2 ways to address this. Change hash/cmp back to ignore co_name and co_firstlineno and then:

1) Never dedup codes, or only dedup codes with the same co_firstlineno (can compare co_name too, but I can't think of a way to create 2 named funcs on the same line). This is pretty much what the current code does.

2) Separate "debug information" (co_filename, co_name, co_firstlineno, co_lnotab) from code object into a separate object. Construct a function from both objects. Allow de-duplication of both. This will always preserve all information in a function, but allows to share code object between identical functions. This is a much more intrusive change, though, e.g. frame will need a reference to debug information.

----------
nosy: +Jeremy.Hylton, brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11983>
_______________________________________

From report at bugs.python.org  Sun May  8 23:23:36 2011
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 08 May 2011 21:23:36 +0000
Subject: [issue11983] Inconsistent hash and comparison for code objects
In-Reply-To: <1304388682.39.0.687842914438.issue11983@psf.upfronthosting.co.za>
Message-ID: <1304889816.77.0.506595859174.issue11983@psf.upfronthosting.co.za>


Eugene Toder <eltoder at gmail.com> added the comment:

Btw, disabling dedup for codes won't be the first exception -- we already avoid coalescing -0.0 with 0.0 for float and complex, even though they compare equal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11983>
_______________________________________

From report at bugs.python.org  Sun May  8 23:25:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 21:25:06 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <BANLkTi=WW6=Xqv_=JjiFA8UyWVdLKwsoKw@mail.gmail.com>
Message-ID: <1304889902.3541.21.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the explanations. This sounds like an interesting path.

> Each thread implementation (thread_pthread.h, thread_nt.h)
> would provide a new PyThread_reinit_lock function that would do the
> right thing (pthread_mutex_destroy/init, sem_destroy/init, etc).
> Modules/threadmodule.c would provide a new PyThread_ReInitLocks that
> would walk through the linked list and call PyThread_reinit_lock for
> each lock.

Actually, I think the issue is POSIX-specific: Windows has no fork(),
and we don't care about other platforms anymore (they are, are being, or
will be soon deprecated).
It means only the POSIX implementation needs to register its locks in a
linked list.

> But this wouldn't allow a lock's state to be inherited across fork for
> the main thread (but like I said, I don't think that this makes much
> sense anyway, and to my knowledge no implementation makes such a
> guarantee - and definitely not POSIX).

Well, the big difference between Python locks and POSIX mutexes is that
Python locks can be released from another thread. They're a kind of
trivial semaphore really, and this makes them usable for other purpose
than mutual exclusion (you can e.g. use a lock as a simple event by
blocking on a second acquire() until another thread calls release()).

But even though we might not be "fixing" arbitrary Python code
automatically, fixing the interpreter's internal locks (especially the
IO locks) would be great already.

(we could also imagine that the creator of the lock decides whether it
should get reinitialized after fork)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun May  8 23:28:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 21:28:23 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304890103.08.0.698383464249.issue9205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here's a patch for the new approach.
CancelIoEx is loaded dynamically and, if unavailable, CancelIo is used instead. I take care to cancel or complete the I/O in the same method call where it is initiated, meaning there's no thread-specificity issues.

(of course, all this is a lot of code just to have the desired WaitForMultipleObjects() semantics on a named pipe. Thank you, Windows)

----------
Added file: http://bugs.python.org/file21937/sentinels4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Mon May  9 00:09:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 22:09:11 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304892551.08.0.755140693952.issue12012@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated patch.

Note: I tried to keep the same enum values for py_ssl_version, it's maybe useless and so "=1" can be removed.

----------
Added file: http://bugs.python.org/file21938/nosslv2-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Mon May  9 00:09:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 22:09:16 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304892556.92.0.551962103173.issue12012@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21902/nosslv2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Mon May  9 00:13:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 22:13:43 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304892551.08.0.755140693952.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304892820.3541.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Updated patch.
> 
> Note: I tried to keep the same enum values for py_ssl_version, it's
> maybe useless and so "=1" can be removed.

Thank you! PROTOCOL_NAMES should stay private and therefore be named
_PROTOCOL_NAMES, IMHO.
Keeping the same enum values is worthwhile, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Mon May  9 00:43:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2011 22:43:46 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <E1QJChU-0002kj-Tu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5296c3e2f166 by Victor Stinner in branch 'default':
Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional
http://hg.python.org/cpython/rev/5296c3e2f166

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Mon May  9 00:44:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 22:44:51 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304894691.19.0.707800332784.issue12012@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/issue12012>
_______________________________________

From report at bugs.python.org  Mon May  9 00:46:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 22:46:38 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <E1QJChU-0002kj-Tu@dinsdale.python.org>
Message-ID: <1304894794.3541.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> New changeset 5296c3e2f166 by Victor Stinner in branch 'default':
> Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional
> http://hg.python.org/cpython/rev/5296c3e2f166

Since it's a bugfix, it should probably go into all branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Mon May  9 00:54:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 22:54:24 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304895264.51.0.473526152652.issue12012@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> 
status: closed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Mon May  9 01:05:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2011 23:05:22 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <E1QJD2M-00041M-Km@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6d1cbfcee45a by Victor Stinner in branch 'default':
Issue #11888: Add log2 function to math module. Patch written by Mark
http://hg.python.org/cpython/rev/6d1cbfcee45a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 01:09:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 23:09:43 +0000
Subject: [issue12011] The signal module should raise OSError for OS-related
	exceptions, not RuntimeError
In-Reply-To: <1304628580.22.0.561171702394.issue12011@psf.upfronthosting.co.za>
Message-ID: <1304896183.96.0.225902888589.issue12011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch: signal.signal() and signal.siginterrupt() raise an OSError, instead of a RuntimeError: OSError has an errno attribute.

----------
keywords: +patch
Added file: http://bugs.python.org/file21939/signal_oserror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12011>
_______________________________________

From report at bugs.python.org  Mon May  9 01:10:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 23:10:19 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304896219.19.0.975080145522.issue10496@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21640/sysconfig_getuserbase.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Mon May  9 01:11:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 23:11:34 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304896294.96.0.80624622822.issue10496@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@eric.araujo, @tarek: do you prefer nonexistent_user.patch? I removed sysconfig_getuserbase.patch, because I agree that an expanded path containing "~" is a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Mon May  9 01:13:06 2011
From: report at bugs.python.org (John O'Connor)
Date: Sun, 08 May 2011 23:13:06 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304896386.11.0.128008274277.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

I experimented with a bunch of different options.

All benchmarks performed with:

$ for i in 1 4 128 256 1024 2048 4069 8192; do 
echo -n "buffer_size=${i} "; 
./python -m timeit -s "f=open('LICENSE','rb');b=bytearray(${i})" \
"f.seek(0)" "while f.readinto(b): pass";
done

with io.DEFAULT_BUFFER_SIZE = 8192

--------------------------------------------------------------------------------
Before patch

buffer_size=1 100 loops, best of 3: 10.4 msec per loop
buffer_size=4 100 loops, best of 3: 2.67 msec per loop
buffer_size=128 10000 loops, best of 3: 102 usec per loop
buffer_size=256 10000 loops, best of 3: 54.9 usec per loop
buffer_size=1024 10000 loops, best of 3: 26.9 usec per loop
buffer_size=2048 10000 loops, best of 3: 20.3 usec per loop
buffer_size=4069 100000 loops, best of 3: 16.3 usec per loop
buffer_size=8192 100000 loops, best of 3: 11.1 usec per loop

--------------------------------------------------------------------------------
Always read into caller's buffer

buffer_size=1 100 loops, best of 3: 14 msec per loop
buffer_size=4 100 loops, best of 3: 4.02 msec per loop
buffer_size=128 10000 loops, best of 3: 114 usec per loop
buffer_size=256 10000 loops, best of 3: 63.7 usec per loop
buffer_size=1024 100000 loops, best of 3: 19.4 usec per loop
buffer_size=2048 100000 loops, best of 3: 11.2 usec per loop
* buffer_size=4069 100000 loops, best of 3: 8.12 usec per loop
* buffer_size=8192 100000 loops, best of 3: 5.79 usec per loop

--------------------------------------------------------------------------------
Read into caller's buffer if java-like bound of internal buffer size is smaller

buffer_size=1 100 loops, best of 3: 5.01 msec per loop
buffer_size=4 1000 loops, best of 3: 1.27 msec per loop
buffer_size=128 10000 loops, best of 3: 46.9 usec per loop
buffer_size=256 10000 loops, best of 3: 29.5 usec per loop
buffer_size=1024 100000 loops, best of 3: 12.9 usec per loop
buffer_size=2048 100000 loops, best of 3: 10.8 usec per loop
buffer_size=4069 100000 loops, best of 3: 9.06 usec per loop
* buffer_size=8192 100000 loops, best of 3: 5.78 usec per loop

--------------------------------------------------------------------------------
Using bound = buffer_size / 2

buffer_size=1 100 loops, best of 3: 6.04 msec per loop
buffer_size=4 1000 loops, best of 3: 1.34 msec per loop
buffer_size=128 10000 loops, best of 3: 49.4 usec per loop
buffer_size=256 10000 loops, best of 3: 29.5 usec per loop
buffer_size=1024 100000 loops, best of 3: 13.2 usec per loop
buffer_size=2048 100000 loops, best of 3: 10.7 usec per loop
* buffer_size=4069 100000 loops, best of 3: 8.66 usec per loop
buffer_size=8192 100000 loops, best of 3: 6.1 usec per loop

--------------------------------------------------------------------------------
Using bound = buffer_size / 4

buffer_size=1 100 loops, best of 3: 5.45 msec per loop
buffer_size=4 1000 loops, best of 3: 1.34 msec per loop
buffer_size=128 10000 loops, best of 3: 49.6 usec per loop
buffer_size=256 10000 loops, best of 3: 28.8 usec per loop
buffer_size=1024 100000 loops, best of 3: 13.1 usec per loop
buffer_size=2048 100000 loops, best of 3: 12.8 usec per loop
buffer_size=4069 100000 loops, best of 3: 8.42 usec per loop
buffer_size=8192 100000 loops, best of 3: 5.93 usec per loop

--------------------------------------------------------------------------------
Always use internal buffer

* buffer_size=1 100 loops, best of 3: 4.53 msec per loop
* buffer_size=4 1000 loops, best of 3: 1.14 msec per loop
* buffer_size=128 10000 loops, best of 3: 45 usec per loop
* buffer_size=256 10000 loops, best of 3: 26.9 usec per loop
* buffer_size=1024 100000 loops, best of 3: 12.9 usec per loop
* buffer_size=2048 100000 loops, best of 3: 10.2 usec per loop
buffer_size=4069 100000 loops, best of 3: 9.15 usec per loop
buffer_size=8192 100000 loops, best of 3: 8.42 usec per loop

--------------------------------------------------------------------------------
Use read() instead

$ for i in 1 4 128 256 1024 2048 4069 8192; do
echo -n "size=${i} "; 
./python -m timeit -s "f=open('LICENSE','rb');" "f.seek(0)" \
"while f.read(${i}): pass";
done

* size=1 100 loops, best of 3: 2.56 msec per loop
* size=4 1000 loops, best of 3: 709 usec per loop
* size=128 10000 loops, best of 3: 29.7 usec per loop
* size=256 100000 loops, best of 3: 18.6 usec per loop
size=1024 100000 loops, best of 3: 13.3 usec per loop
size=2048 100000 loops, best of 3: 10.8 usec per loop
size=4069 100000 loops, best of 3: 10.1 usec per loop
size=8192 100000 loops, best of 3: 6.41 usec per loop

--------------------------------------------------------------------------------


Based on the above I think you are right about using the internal buffer
regardless (revision attached). You pay a price with larger buffer sizes but on
balance it seems to be a much better general purpose solution. The java-like 
solution is decent as well, it is only slightly slower for small reads and optimal
for larger buffer sizes. Personally, I would opt for the performance with larger
buffer sizes but I can only speculate as to what the general user would do. We
could always note the trade-off in the docs.

Interestingly enough it seems like using read() is a better idea
if you use a smaller size (how is that right?).

I attached the afformentioned revisions.

----------
Added file: http://bugs.python.org/file21940/issue9971.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Mon May  9 01:13:46 2011
From: report at bugs.python.org (John O'Connor)
Date: Sun, 08 May 2011 23:13:46 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304896426.42.0.500160062625.issue9971@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


Added file: http://bugs.python.org/file21941/issue9971-like-java.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Mon May  9 01:19:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 May 2011 23:19:43 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304896783.79.0.376095019527.issue9971@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It would be nice if you can also patch _pyio. I read sometimes _pyio to check how _io is implemented.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Mon May  9 01:21:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 May 2011 23:21:41 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1304896783.79.0.376095019527.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304896897.3541.25.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It would be nice if you can also patch _pyio. I read sometimes _pyio
> to check how _io is implemented.

Well, _pyio implements the same APIs but it doesn't necessarily use the
same algorithms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Mon May  9 01:29:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2011 23:29:34 +0000
Subject: [issue12032] Tools/Scripts/crlv.py needs updating for python 3+
In-Reply-To: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>
Message-ID: <E1QJDPn-0005K1-SB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f94d74c85dcb by Victor Stinner in branch 'default':
Close #12032: Fix scripts/crlf.py for Python 3
http://hg.python.org/cpython/rev/f94d74c85dcb

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12032>
_______________________________________

From report at bugs.python.org  Mon May  9 03:46:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 May 2011 01:46:38 +0000
Subject: [issue12025] strangely missing separator in "resource" table
In-Reply-To: <1304734977.84.0.0748743077356.issue12025@psf.upfronthosting.co.za>
Message-ID: <1304905598.08.0.639661577195.issue12025@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If I zoom out (Ctrl+-) with FF4 one of the lines (the one between 9 and 10 for me) disappear.  Try Ctrl+0 to fix it.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12025>
_______________________________________

From report at bugs.python.org  Mon May  9 04:24:30 2011
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 09 May 2011 02:24:30 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1304907870.92.0.412004757999.issue9923@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

It's just theoretical. A web search shows that a few Windows programs, like PC Pine, can use $MAILCAPS. But none of those tools look recent, like you said.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Mon May  9 04:30:41 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 09 May 2011 02:30:41 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304908241.72.0.161035946208.issue8407@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/issue8407>
_______________________________________

From report at bugs.python.org  Mon May  9 04:53:11 2011
From: report at bugs.python.org (Mathieu Bridon)
Date: Mon, 09 May 2011 02:53:11 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1304909591.5.0.207954636372.issue9584@psf.upfronthosting.co.za>


Mathieu Bridon <bochecha at fedoraproject.org> added the comment:

Is anybody still reading this? :-/

Could somebody commit the patch, reject it, or tell me what else I need to do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Mon May  9 05:06:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 09 May 2011 03:06:05 +0000
Subject: [issue12025] strangely missing separator in "resource" table
In-Reply-To: <1304734977.84.0.0748743077356.issue12025@psf.upfronthosting.co.za>
Message-ID: <1304910365.23.0.202025648132.issue12025@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Cntl+0 "fixes" it. I was not aware of having set a zoom level for python website.

Sorry for wasting your time.

PS: FF should no "drop" details like that. Whatever :).

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12025>
_______________________________________

From report at bugs.python.org  Mon May  9 05:29:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 03:29:14 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <E1QJH9V-00031s-Ox@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c1a12a308c5b by Ezio Melotti in branch '2.7':
#11910: change import_fresh_module to return None when one of the "fresh" modules can not be imported.
http://hg.python.org/cpython/rev/c1a12a308c5b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Mon May  9 05:35:58 2011
From: report at bugs.python.org (Kasun Herath)
Date: Mon, 09 May 2011 03:35:58 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1304912158.39.0.297279056769.issue8809@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

Yes, I would like to have a try at it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Mon May  9 05:44:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 03:44:48 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <E1QJHOp-0003jo-Bi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3ab1eb027856 by Ezio Melotti in branch '3.1':
#11910: change import_fresh_module to return None when one of the "fresh" modules can not be imported.
http://hg.python.org/cpython/rev/3ab1eb027856

New changeset 754bafe8db5f by Ezio Melotti in branch '3.2':
#11910: merge with 3.1.
http://hg.python.org/cpython/rev/754bafe8db5f

New changeset 3e8f0111feed by Ezio Melotti in branch 'default':
#11910: merge with 3.2.
http://hg.python.org/cpython/rev/3e8f0111feed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Mon May  9 06:30:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 04:30:40 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <E1QJI7A-0006km-IT@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3cbbb2a7c56d by Ezio Melotti in branch '2.7':
#11910: Fix test_heapq to skip the C tests when _heapq is missing.
http://hg.python.org/cpython/rev/3cbbb2a7c56d

New changeset 677ee366c9f5 by Ezio Melotti in branch '3.1':
#11910: Fix test_heapq to skip the C tests when _heapq is missing.
http://hg.python.org/cpython/rev/677ee366c9f5

New changeset 4f3f67a595fb by Ezio Melotti in branch '3.2':
#11910: merge with 3.1.
http://hg.python.org/cpython/rev/4f3f67a595fb

New changeset 3449406fd04a by Ezio Melotti in branch 'default':
#11910: merge with 3.2.
http://hg.python.org/cpython/rev/3449406fd04a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Mon May  9 07:43:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 05:43:41 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <E1QJJFo-000338-A6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 749686064642 by Martin v. L?wis in branch '3.2':
Use --as-needed when linking libpython3.so. Closes #11347.
http://hg.python.org/cpython/rev/749686064642

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Mon May  9 07:46:56 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 May 2011 05:46:56 +0000
Subject: [issue12026] Support more of MSI api by exposing handles
In-Reply-To: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>
Message-ID: <1304920016.75.0.417420446674.issue12026@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd rather expose the missing functions, than supporting a mix of this module with a ctypes one; this patch sounds hackish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12026>
_______________________________________

From report at bugs.python.org  Mon May  9 07:48:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 May 2011 05:48:58 +0000
Subject: [issue11910] test_heapq C tests are not skipped when _heapq is missing
In-Reply-To: <1303524259.87.0.426176819457.issue11910@psf.upfronthosting.co.za>
Message-ID: <1304920138.1.0.619909099757.issue11910@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11910>
_______________________________________

From report at bugs.python.org  Mon May  9 08:00:32 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 May 2011 06:00:32 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1304920832.94.0.12799047458.issue11164@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

allnodes was deleted in 5b3fbff05ffd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Mon May  9 08:16:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 06:16:55 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <E1QJJm1-0005CV-L6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 61798f076676 by Martin v. L?wis in branch '3.1':
Stop trying to use _xmlplus in the xml module. Closes #11164.
http://hg.python.org/cpython/rev/61798f076676

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Mon May  9 08:19:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 06:19:54 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <E1QJJos-0005G9-Dm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6c7984bae459 by Martin v. L?wis in branch '2.7':
Issue 11164: Remove obsolete allnodes test from minidom test.
http://hg.python.org/cpython/rev/6c7984bae459

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Mon May  9 09:47:23 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2011 07:47:23 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304927243.72.0.918613590746.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Victor.  You caught me by surprise a bit:  I had some more minor changes to that patch pending, so I've committed those separately.

Any news from the buildbots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 09:49:39 2011
From: report at bugs.python.org (sulakshana)
Date: Mon, 09 May 2011 07:49:39 +0000
Subject: [issue12035] problem with installing validator.nu on windows
In-Reply-To: <1304927379.74.0.0716005360377.issue12035@psf.upfronthosting.co.za>
Message-ID: <1304927379.74.0.0716005360377.issue12035@psf.upfronthosting.co.za>


New submission from sulakshana <sulakshana.03 at gmail.com>:

I tried following instructions given in http://about.validator.nu/#src to install validator.nu on windows. 1. changed hg clone https://bitbucket.org/validator/build build to hg.py clone https://bitbucket.org/validator/build build as HG was not getting recognised in windows. 2. when i tried to run python build/build.py all getting the following error..

pasting the entire thing... how to solve this???

C:\www\checker>python build/build.py all "hg.py" pull --update -R build https://bitbucket.org/validator/build/ Traceback (most recent call last): File "build/build.py", line 1041, in selfUpdate()

File "build/build.py", line 797, in selfUpdate hgCloneOrUpdate("build", hgRoot)

File "build/build.py", line 777, in hgCloneOrUpdate runCmd('"%s" pull --update -R %s %s%s/' % (hgCmd, mod, baseUrl, mod))

File "build/build.py", line 173, in runCmd subprocess.call(cmd)

File "C:\www\Python27\lib\subprocess.py", line 486, in call return Popen(*popenargs, **kwargs).wait()

File "C:\www\Python27\lib\subprocess.py", line 672, in init errread, errwrite)

File "C:\www\Python27\lib\subprocess.py", line 882, in _execute_child startupinfo)

WindowsError: [Error 193] %1 is not a valid Win32 application

----------
components: Windows
messages: 135570
nosy: sulakshana
priority: normal
severity: normal
status: open
title: problem with installing validator.nu on windows
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12035>
_______________________________________

From report at bugs.python.org  Mon May  9 10:30:31 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 09 May 2011 08:30:31 +0000
Subject: [issue12035] problem with installing validator.nu on windows
In-Reply-To: <1304927379.74.0.0716005360377.issue12035@psf.upfronthosting.co.za>
Message-ID: <1304929831.34.0.0202701656877.issue12035@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is not a python issue. Please report your problem to the validator project.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12035>
_______________________________________

From report at bugs.python.org  Mon May  9 11:15:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 09:15:30 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304932530.81.0.106105359337.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Thanks, Victor.  You caught me by surprise a bit

Oh, I thought that the patch was ready to be commited.

> I had some more minor changes to that patch pending,
> so I've committed those separately.

You should add "Issue #11888: " prefix to your commit messages so a bot automatically add comments for the new commits to this issue.

> "Fix cut-and-paste typo in comment: log10 -> log2."

Oh, I didn't notice it, but Terry Reedy

> "Fix nonunique test ids in math_testcases.txt."

Oh, I didn't notice it: why do we need explicit identifiers? Can't we use the line number or something like that? What happens if two tests have the same identifier? Is the first test skipped?

> Any news from the buildbots?

Yes, most of them are happy. Some of them are busy (don't have test log2() yet), others are unhappy but not because of log2(). Said differently: log2 tests pass on most buildbots, but we have to wait 12 hours or maybe one day to wait for all buildbots.

If the test pass on all buildbots, I will commit issue11888-part2.patch to use the system log2 function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 12:16:30 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 09 May 2011 10:16:30 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1304843636.1.0.337031197286.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110509101621.GA10416@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ronald Oussoren wrote (2011-05-08 10:33+0200):
> Steffen, I don't understand your comment about "auto". Declaring
> variables as "auto" is not necessary in C code and not used
> anywhere else in Python's source code.

Well, as long as i can keep my underwear all is fine.
(I also looked at Google translate because i first wanted to start
the reply with "croak .. pip .. twist .. wrench .. groan .. ugh".)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Mon May  9 12:24:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 10:24:23 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <E1QJNdT-0008FN-NE@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c6523d6faef4 by Gerhard Haering in branch 'default':
#10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now.
http://hg.python.org/cpython/rev/c6523d6faef4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10811>
_______________________________________

From report at bugs.python.org  Mon May  9 12:34:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 10:34:16 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304937256.7.0.898603287958.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> we have to wait 12 hours or maybe one day to wait for all buildbots

Oh, it's faster than expected: test_math passed on FreeBSD 6.4 3.x buildbot. I was waiting for this one because it's an old OS and many tests fail on this buildbot (because it's old but also slow). So test_math passed on all buildbots. Let's try the system log2 :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 12:46:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 10:46:33 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <E1QJNyy-00028y-F1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 565f43f6bed4 by Victor Stinner in branch 'default':
Issue #11888: Use system log2() when available
http://hg.python.org/cpython/rev/565f43f6bed4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 14:10:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 12:10:13 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304943013.84.0.527719124859.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #11888: Use system log2() when available
http://hg.python.org/cpython/rev/565f43f6bed4

"I expect the system libc to use more accurate functions than Python."

You know what? Mac OS X log2 is less accurate than Python log2! A log2 test failed on "x86 Tiger 3.x":

http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2488
======================================================================
FAIL: testLog2 (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_math.py", line 658, in testLog2
    self.assertEqual(actual, expected)
AssertionError: Lists differ: [-324.0, -323.0, -322.0, -321.... != [-324.0, -323.0, -322.0, -321....

First differing element 69:
-254.99999999999997
-255.0
----------------------------------------------------------------------

Should I revert my patch or should we test the system log2 in configure to check if it is as accurate or more accurate than Mark's algorithm?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 14:17:41 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2011 12:17:41 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304943461.11.0.313869903659.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> You know what? Mac OS X log2 is less accurate than Python log2!

That doesn't surprise me much.  Though it's probably still true that log2 from OS X is more accurate than our log2 for some other values.  It's just that getting the answer wrong for a power of 2 is a 'high-visibility' error.

Testing log2 sounds long-winded and error-prone.  I'd suggest just marking that test as an expected failure on Tiger.  BTW, I don't see any such failure on Snow Leopard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 14:20:14 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2011 12:20:14 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304943614.01.0.622149155623.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

One other thought:  we should check that it's not pow that's at fault here, rather than log2.  The test uses math.log2(2.0**n).  It would probably be better off using math.log2(ldexp(1.0, n)), or similar:  the libm pow operation is also notorious for inaccuracies (due to poor implementations or otherwise) on various platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 14:26:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 May 2011 12:26:19 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1304943979.48.0.700443977272.issue8407@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

There are warnings on the FreeBSD and OSX buildbots, where pthread_t
is not a long.

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/237/steps/compile/logs/warnings%20%283%29

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/1336/steps/compile/logs/warnings%20%2828%29

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Mon May  9 14:46:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 12:46:25 +0000
Subject: [issue10811] sqlite segfault with generators
In-Reply-To: <1294018427.94.0.141740646278.issue10811@psf.upfronthosting.co.za>
Message-ID: <E1QJPqs-0005Xv-QF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2fdabf0dc8f7 by Victor Stinner in branch 'default':
Issue #10811: Use TestCase.assertRaises() in the new test
http://hg.python.org/cpython/rev/2fdabf0dc8f7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10811>
_______________________________________

From report at bugs.python.org  Mon May  9 14:46:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 12:46:25 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QJPqs-0005Xv-QN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2e0d3092249b by Victor Stinner in branch 'default':
Issue #8407: Use an explicit cast for FreeBSD
http://hg.python.org/cpython/rev/2e0d3092249b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Mon May  9 14:50:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 12:50:47 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304945447.81.0.388594193202.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> we should check that it's not pow that's at fault here

Some tests on Mac OS X Tiger:

>>> (2.0 ** -255).hex()
'0x1.0000000000000p-255'

=> pow is correct

>>> import ctypes; import ctypes.util, math
>>> libc = ctypes.cdll.LoadLibrary(ctypes.util.find_library('c'))
>>> clog2=libc.log2
>>> clog2.restype=ctypes.c_double
>>> clog2.argtypes=(ctypes.c_double,)
>>> clog2(2.0**-255)
-254.99999999999997
>>> math.log(2.0**-255) / math.log(2.0)
-255.0

>>> math.log(2.0**-255)
-176.75253104278605
>>> math.log(2.0**-255).hex()
'-0x1.61814bbfb3fb5p+7'
>>> math.log(2.0)
0.6931471805599453
>>> math.log(2.0).hex()
'0x1.62e42fefa39efp-1'

>>> clog2(2.0**-255).hex()
'-0x1.fdfffffffffffp+7'
>>> (math.log(2.0**-255) / math.log(2.0)).hex()
'-0x1.fe00000000000p+7'

clog2() is wrong for 2^-255.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 15:02:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 13:02:54 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <E1QJQ6r-0006lQ-Jj@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1f23d63b578c by Mark Dickinson in branch 'default':
Issue #11188: In log2 tests, create powers of 2 using ldexp(1, n) instead of the less reliable 2.0**n.
http://hg.python.org/cpython/rev/1f23d63b578c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Mon May  9 15:04:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2011 13:04:07 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304946247.34.0.587810682577.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, thanks.  We should still be using ldexp rather than 2.0**... in the tests, though;  I've fixed this, and also fixed the incorrect (too small) range for those tests, so that all representable powers of 2 are now covered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 15:19:06 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2011 13:19:06 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1304947146.47.0.964586848431.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Grr.  Got the issue number wrong in the commit message;  see msg135584.


New changeset 1f23d63b578c by Mark Dickinson in branch 'default':
Issue #11188: In log2 tests, create powers of 2 using ldexp(1, n) instead of the less reliable 2.0**n.
http://hg.python.org/cpython/rev/1f23d63b578c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Mon May  9 15:19:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2011 13:19:22 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1304947162.48.0.558082769688.issue11188@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
Removed message: http://bugs.python.org/msg135584

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Mon May  9 15:32:25 2011
From: report at bugs.python.org (Tim Golden)
Date: Mon, 09 May 2011 13:32:25 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1304947945.33.0.56405210862.issue9584@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

I've just rebuilt on Windows against tip. test_glob is failing:

test test_glob failed -- Traceback (most recent call last):
  File "c:\work-in-progress\python\cpython-9584\lib\test\test_glob.py", line 135, in test_glob_curly_braces
    os.path.join('a', 'bcd', 'efg')]))
  File "c:\work-in-progress\python\cpython-9584\lib\test\test_glob.py", line 53, in assertSequencesEqual_noorder
    self.assertEqual(set(l1), set(l2))
AssertionError: Items in the first set but not the second:
'@test_2788_tmp_dir\\a/bcd\\efg'
'@test_2788_tmp_dir\\a/bcd\\EF'
Items in the second set but not the first:
'@test_2788_tmp_dir\\a\\bcd\\EF'
'@test_2788_tmp_dir\\a\\bcd\\efg'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Mon May  9 16:04:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 May 2011 14:04:57 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1304949897.61.0.664405307394.issue9584@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+        if sub.find(',') != -1:
Please use the 'in' operator here.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Mon May  9 16:29:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 May 2011 14:29:00 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304951340.01.0.943869228008.issue10666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No.  You wrote this: ?Here's a snippet of what I have in my startup file: [code with if 'libedit' in readline.__doc__ complication] While obviously this can be handled, it seems like an unnecessary burden on users.?  My message addresses this: using read_init_file removes the need for this complication (the four lines with the in test).  IOW, I was suggesting that we could add a mention of libedit in the readline docs and advise that people use read_init_file, then close this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Mon May  9 16:30:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 May 2011 14:30:16 +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: <1304951416.72.0.712467422164.issue12013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It would be helpful if you could attach the test log.  Alternatively, if the configure and build log for your Python package is available somewhere on the web, the link would be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Mon May  9 16:37:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 May 2011 14:37:30 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <1304951850.37.0.583452218574.issue11968@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11968>
_______________________________________

From report at bugs.python.org  Mon May  9 16:38:21 2011
From: report at bugs.python.org (Isaac Jurado)
Date: Mon, 09 May 2011 14:38:21 +0000
Subject: [issue12036] ConfigParser: items() adds the vars dictionary to the
	result
In-Reply-To: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>
Message-ID: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>


New submission from Isaac Jurado <ijurado at econcept.es>:

>From the following python code:

import os
from ConfigParser import ConfigParser
from pprint import pprint
c = ConfigParser()
c.read(['test.ini'])
pprint(c.items('test', raw=False, vars=os.environ))

I see the values contained in os.environ as well as in section "test" (in the attached configuration example).

The problem seems to come from the following line:

http://hg.python.org/cpython/file/5395f96588d4/Lib/ConfigParser.py#l605

Which is fixed in py3k but for the 2.x branch has not been modified sin 2002:

http://hg.python.org/cpython/annotate/8bb6003f7f54/Lib/ConfigParser.py#514

----------
components: Library (Lib)
files: test.ini
messages: 135591
nosy: Isaac.Jurado
priority: normal
severity: normal
status: open
title: ConfigParser: items() adds the vars dictionary to the result
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21942/test.ini

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12036>
_______________________________________

From report at bugs.python.org  Mon May  9 16:40:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 May 2011 14:40:05 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304952005.63.0.111894984266.issue10496@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In the absence of tests or doc update, can you tell in English what the new behavior is?  IIUC, when the home dir is not found, all the variables that depend on it would not exist, right?  Or would they be set to None?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Mon May  9 16:40:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 May 2011 14:40:38 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1304952038.53.0.038966823744.issue9923@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay.  Nonetheless, splitting on os.sep doesn?t cost us anything and is IMO a good practice to follow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Mon May  9 16:57:12 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 09 May 2011 14:57:12 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304953032.37.0.497577185339.issue8498@psf.upfronthosting.co.za>


Changes by Daniel Evers <dermojo at googlemail.com>:


Removed file: http://bugs.python.org/file17065/backlog0.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 16:57:14 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 09 May 2011 14:57:14 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304953034.87.0.331415870581.issue8498@psf.upfronthosting.co.za>


Changes by Daniel Evers <dermojo at googlemail.com>:


Removed file: http://bugs.python.org/file17066/backlog0_incl_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 16:57:17 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 09 May 2011 14:57:17 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304953037.13.0.00463351810293.issue8498@psf.upfronthosting.co.za>


Changes by Daniel Evers <dermojo at googlemail.com>:


Removed file: http://bugs.python.org/file17067/socket_listen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 16:57:19 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 09 May 2011 14:57:19 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304953039.57.0.0233898318258.issue8498@psf.upfronthosting.co.za>


Changes by Daniel Evers <dermojo at googlemail.com>:


Removed file: http://bugs.python.org/file21851/server.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 16:57:21 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 09 May 2011 14:57:21 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304953041.93.0.137886748326.issue8498@psf.upfronthosting.co.za>


Changes by Daniel Evers <dermojo at googlemail.com>:


Removed file: http://bugs.python.org/file21852/client.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 16:57:24 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 09 May 2011 14:57:24 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304953044.21.0.746115687712.issue8498@psf.upfronthosting.co.za>


Changes by Daniel Evers <dermojo at googlemail.com>:


Removed file: http://bugs.python.org/file21879/backlog0_complete.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 17:01:04 2011
From: report at bugs.python.org (Daniel Evers)
Date: Mon, 09 May 2011 15:01:04 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1304953264.04.0.205589524384.issue8498@psf.upfronthosting.co.za>


Daniel Evers <dermojo at googlemail.com> added the comment:

Thanks, I removed the old patches and changed the unit test according to your suggestion.
I kept the "usually 5" remark, because I'm not sure how reality really looks like. But feel free to suggest a patch ;)

----------
Added file: http://bugs.python.org/file21943/socket_backlog0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 17:10:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 15:10:42 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <E1QJS6b-000210-7C@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1ac03e071d65 by Antoine Pitrou in branch 'default':
Issue #11743: Rewrite multiprocessing connection classes in pure Python.
http://hg.python.org/cpython/rev/1ac03e071d65

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11743>
_______________________________________

From report at bugs.python.org  Mon May  9 17:10:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 15:10:48 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory (sysconfig._getuserbase)
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1304953848.59.0.0638902014864.issue10496@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Main changes of the patch, if the current user has no home directory (no entry in /etc/passwd) and there is HOME environment variable:

 - sysconfig.get_config_vars() doesn't have a 'userbase' variable. sysconfig.get_config_var('userbase') returns None as any other nonexistent key.
 - sysconfig.get_paths() doesn't create a path if expand fails (without raising an error or emiting a warning). For example, sysconfig.get_paths(scheme='posix_user') returns an empty dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Mon May  9 17:13:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 15:13:09 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1304953989.29.0.213684704733.issue11743@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now checked in, hopefully there will be no buildbot failures.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11743>
_______________________________________

From report at bugs.python.org  Mon May  9 17:15:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 May 2011 15:15:49 +0000
Subject: [issue12036] ConfigParser: items() adds the vars dictionary to the
	result
In-Reply-To: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>
Message-ID: <1304954149.41.0.175962039266.issue12036@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12036>
_______________________________________

From report at bugs.python.org  Mon May  9 17:25:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 15:25:24 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <E1QJSKh-0003Ll-VN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 25298224cb25 by Senthil Kumaran in branch 'default':
Issue #3709: a flush_headers method to BaseHTTPRequestHandler which manages the
http://hg.python.org/cpython/rev/25298224cb25

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Mon May  9 17:26:42 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 09 May 2011 15:26:42 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1304954802.03.0.991230117778.issue3709@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Added the flush_headers method and the test function. this issue can be closed now. Thanks, Andrew Schaaf.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Mon May  9 17:29:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 15:29:40 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1304954980.07.0.902338235856.issue8305@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8305>
_______________________________________

From report at bugs.python.org  Mon May  9 17:32:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 15:32:19 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1304955139.17.0.541816905188.issue5231@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In the mean time I had to resort to dirty hacks in 1ac03e071d65 (such as using io.BytesIO.write(), which I know is implemented in C and doesn't care about item size).

At the minimum, a memoryview.getflatview() function would be nice (and probably easier to code than the generic version). Or a "flat" optional argument in the memoryview constructor.

----------
stage: test needed -> patch review
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Mon May  9 17:32:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 15:32:23 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1304955143.41.0.811699112841.issue5231@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Mon May  9 17:35:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 15:35:32 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1304955332.79.0.211159102324.issue5231@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Read a int32 array as a raw byte string is useful, but the opposite is also useful.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Mon May  9 17:37:56 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 09 May 2011 15:37:56 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1304955476.68.0.37022213869.issue3709@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Mon May  9 17:40:05 2011
From: report at bugs.python.org (Alan Kennedy)
Date: Mon, 09 May 2011 15:40:05 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
	sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1304955605.25.0.461171676899.issue3566@psf.upfronthosting.co.za>


Changes by Alan Kennedy <python-dev at xhaus.com>:


----------
nosy: +amak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Mon May  9 17:49:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 15:49:44 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1304956184.12.0.61935740191.issue11743@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11743>
_______________________________________

From report at bugs.python.org  Mon May  9 18:05:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 May 2011 16:05:27 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304957127.37.0.19278035371.issue12015@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Python should still work reliably even if the temp directory is on a case-insensitive filesystem. Since that isn't an easy thing to determine, -1 on restoring the uppercase characters to the filenames.

As for it not being fixed previously, it's a rare bug that only affects case-insensitive filesystems. Just because other groups have decided not to care about it (typically due to a heavy bias towards case-sensitive POSIX filesystems), that is no reason for us to ignore it once we're aware of it.

If we really wanted to increase the entropy, better to increase the number of random characters included in the name to 7 or 8 (with each additional character increasing the pool size by a factor of 37). After all, why perpetuate an arbitrary restriction that is due primarily to the difficulty of constructing nice string manipulation interfaces in C?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:09:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 16:09:04 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304957344.25.0.858375912343.issue12015@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If you would like more entry, use a longer filename:

>>> (26+10+1) ** 6 > (26+26+10+1) ** 6
False
>>> (26+10+1) ** 7 > (26+26+10+1) ** 6
True

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:15:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 May 2011 16:15:25 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304957725.4.0.550728711233.issue12015@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The number of characters in the filename is hardcoded in the guts of tempfile (in _RandomNameSequence.__next__ to be exact). Increasing that to 7 (or even 8) would be a straightforward change at the library level, but it can't be done from user code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:20:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 May 2011 16:20:54 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304958054.24.0.0351419612823.issue12015@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Could someone explain me what's the risk on a case-insensitive filesystem?
Since files are created with O_CREAT|O_EXCL, I don't see where the problem is.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:33:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 16:33:49 +0000
Subject: [issue12037] test_email failures under Windows with the eol extension
	activated
In-Reply-To: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>
Message-ID: <1304958829.88.0.465488458456.issue12037@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The title says it all. Ideally (!), changing .hgignore should be enough to fix this issue.
(NB: I have only tested the default branch)

======================================================================
FAIL: test_byte_message_rfc822_only (test_email.TestMessageAPI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\t\cp\lib\test\test_email\test_email.py", line 189, in test_byte_messa
ge_rfc822_only
    self.assertEqual(out.getvalue(), msgdata)
AssertionError: Lists differ: ["b'Return-Path: <sender at examp... != ["b'Return-Pa
th: <sender at examp...

First differing element 0:
b'Return-Path: <sender at example.net>\n'
b'Return-Path: <sender at example.net>\r\n'

- ["b'Return-Path: <sender at example.net>\\n'",
+ ["b'Return-Path: <sender at example.net>\\r\\n'",
?                                        +++

-  "b'Delivery-Date: Mon, 08 Feb 2010 14:05:16 +0100\\n'",
+  "b'Delivery-Date: Mon, 08 Feb 2010 14:05:16 +0100\\r\\n'",
?                                                     +++

-  "b'Received: from example.org (example.org [64.5.53.58])\\n'",
+  "b'Received: from example.org (example.org [64.5.53.58])\\r\\n'",
?                                                            +++

-  "b'    by example.net (node=mxbap2) with ESMTP (Nemesis)\\n'",
+  "b'    by example.net (node=mxbap2) with ESMTP (Nemesis)\\r\\n'",
?                                                            +++

-  "b'    id UNIQUE for someone at example.com; Mon, 08 Feb 2010 14:05:16 +0100\\n'
",
+  "b'    id UNIQUE for someone at example.com; Mon, 08 Feb 2010 14:05:16 +0100\\r\
\n'",
?                                                                             ++
+

-  "b'Date: Mon, 01 Feb 2010 12:21:16 +0100\\n'",
+  "b'Date: Mon, 01 Feb 2010 12:21:16 +0100\\r\\n'",
?                                            +++

-  'b\'From: "Sender" <sender at example.net>\\n\'',
+  'b\'From: "Sender" <sender at example.net>\\r\\n\'',
?                                           +++

-  "b'To: <someone at example.com>\\n'",
+  "b'To: <someone at example.com>\\r\\n'",
?                                +++

-  "b'Subject: GroupwiseForwardingTest\\n'",
+  "b'Subject: GroupwiseForwardingTest\\r\\n'",
?                                       +++

-  "b'Mime-Version: 1.0\\n'",
+  "b'Mime-Version: 1.0\\r\\n'",
?                      +++

-  "b'Content-Type: message/rfc822\\n'",
+  "b'Content-Type: message/rfc822\\r\\n'",
?                                   +++

-  "b'\\n'",
+  "b'\\r\\n'",
?     +++

   "b'Return-path: <sender at example.net>\\r\\n'",
   "b'Message-ID: <4B66B890.4070408 at teconcept.de>\\r\\n'",
   "b'Date: Mon, 01 Feb 2010 12:18:40 +0100\\r\\n'",
   'b\'From: "Dr. Sender" <sender at example.net>\\r\\n\'',
   "b'MIME-Version: 1.0\\r\\n'",
   'b\'To: "Recipient" <recipient at example.com>\\r\\n\'',
   "b'Subject: GroupwiseForwardingTest\\r\\n'",
   "b'Content-Type: text/plain; charset=ISO-8859-15\\r\\n'",
   "b'Content-Transfer-Encoding: 7bit\\r\\n'",
   "b'\\r\\n'",
   "b'Testing email forwarding with Groupwise 1.2.2010\\r\\n'"]

======================================================================
FAIL: test_flatten_linesep_overrides_policy (test_email.TestParsers)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\t\cp\lib\test\test_email\test_email.py", line 3074, in test_flatten_l
inesep_overrides_policy
    self.assertEqual(s.getvalue(), text)
AssertionError: 'Return-Path: <aperson at dom.ain>\nReceived: by mail.dom.ain (Post
fix, from userid [truncated]... != 'Return-Path: <aperson at dom.ain>\r\nReceived:
by mail.dom.ain (Postfix, from user [truncated]...
- Return-Path: <aperson at dom.ain>
+ Return-Path: <aperson at dom.ain>
?                               +
- Received: by mail.dom.ain (Postfix, from userid 889)
+ Received: by mail.dom.ain (Postfix, from userid 889)
?                                                     +
-       id B9D0AD35DB; Tue,  4 Jun 2002 21:46:59 -0400 (EDT)
+       id B9D0AD35DB; Tue,  4 Jun 2002 21:46:59 -0400 (EDT)
?                                                           +
- Message-ID: <15613.28051.707126.569693 at dom.ain>
+ Message-ID: <15613.28051.707126.569693 at dom.ain>
?                                                +
- Date: Tue, 4 Jun 2002 21:46:59 -0400
+ Date: Tue, 4 Jun 2002 21:46:59 -0400
?                                     +
- MIME-Version: 1.0
+ MIME-Version: 1.0
?                  +
- Content-Type: text/plain; charset=us-ascii
+ Content-Type: text/plain; charset=us-ascii
?                                           +
- Content-Transfer-Encoding: 7bit
+ Content-Transfer-Encoding: 7bit
?                                +
- Subject: bug demonstration
+ Subject: bug demonstration
?                           +
-       123456789112345678921234567893123456789412345678951234567896123456789712
34567898112345678911234567892123456789112345678911234567892123456789
+       123456789112345678921234567893123456789412345678951234567896123456789712
34567898112345678911234567892123456789112345678911234567892123456789
?
                                                                    +
-       more text
+       more text
?                +
- From: aperson at dom.ain (Anne P. Erson)
+ From: aperson at dom.ain (Anne P. Erson)
?                                      +
- To: bperson at dom.ain (Barney P. Erson)
+ To: bperson at dom.ain (Barney P. Erson)
?                                      +
-
+
  test


----------------------------------------------------------------------
Ran 502 tests in 4.438s

FAILED (failures=3, skipped=1)

----------
assignee: r.david.murray
components: Tests
messages: 135606
nosy: pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: test_email failures under Windows with the eol extension activated
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12037>
_______________________________________

From report at bugs.python.org  Mon May  9 18:35:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 May 2011 16:35:00 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304958900.0.0.884878168868.issue12015@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Basically, adding the uppercase letters back in would provide no gain in entropy on a case-insensitive filesystem (as the upper and lower case letters will collide). Increasing the length of the random sequence would provide a consistent gain regardless of filesystem properties.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:36:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 16:36:52 +0000
Subject: [issue12038] assertEqual doesn't display newline differences quite
	well
In-Reply-To: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>
Message-ID: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

>>> tc.assertEqual("x\n" * 40 + "\n", "x\n" * 40 + "\r\n")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 662, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 1041, in assertMultiLineEqual
    self.fail(self._formatMessage(msg, standardMsg))
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 531, in fail
    raise self.failureException(msg)
AssertionError: 'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx [truncated]... != 'x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx [truncated]...
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
  x
- 
+ 


It isn't obvious when looking at this printout that the last newline differed.

----------
components: Library (Lib)
messages: 135608
nosy: ezio.melotti, michael.foord, pitrou
priority: low
severity: normal
status: open
title: assertEqual doesn't display newline differences quite well
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12038>
_______________________________________

From report at bugs.python.org  Mon May  9 18:37:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 May 2011 16:37:37 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304959057.57.0.270009243166.issue12015@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for increasing the number of random characters to 8
-1 for restoring uppercase letters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:40:07 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 May 2011 16:40:07 +0000
Subject: [issue12036] ConfigParser: items() adds the vars dictionary to the
	result
In-Reply-To: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>
Message-ID: <1304959207.65.0.875281766782.issue12036@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This annoyance can't be fixed in 2.x anymore since this is a change of behaviour requiring a full release. While it is very unlikely someone depended on this "feature", changing it breaks compatibility.

Reclassified as `Documentation` to explicitly describe that change in 3.2.

----------
assignee:  -> lukasz.langa
components: +Documentation -Library (Lib)
priority: normal -> low
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12036>
_______________________________________

From report at bugs.python.org  Mon May  9 18:48:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 May 2011 16:48:24 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304959704.1.0.247222797508.issue12015@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Minor clarification: after my first comment, I realised that the original change in the character set didn't actually fix anything, it just propagated the effectively smaller sample space on case-insensitive filesystems to all filesystems. Increasing the number of random characters to 8 will more than compensate for that reduction while retaining the cross-platform consistency in behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:49:17 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 May 2011 16:49:17 +0000
Subject: [issue12036] ConfigParser: Document items() added the vars dictionary
	to the result
In-Reply-To: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>
Message-ID: <1304959757.48.0.180652109904.issue12036@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
title: ConfigParser: items() adds the vars dictionary to the result -> ConfigParser: Document items() added the vars dictionary to the result

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12036>
_______________________________________

From report at bugs.python.org  Mon May  9 18:50:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 May 2011 16:50:12 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304959812.44.0.528451428252.issue12015@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

@Nick
I fully agree with you, but my point was that it doesn't make it less safe on case-insensitive filesystems.
Apart from that, it's of course better to increase the length of the random sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 18:51:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 16:51:09 +0000
Subject: [issue12036] ConfigParser: Document items() added the vars dictionary
	to the result
In-Reply-To: <1304951901.69.0.838316946383.issue12036@psf.upfronthosting.co.za>
Message-ID: <E1QJTfn-0003Em-RQ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 62e2b74c3bfc by ?ukasz Langa in branch '3.2':
Closes #12036: ConfigParser: Document items() added the vars dictionary to the result
http://hg.python.org/cpython/rev/62e2b74c3bfc

New changeset 2d984cc4afb0 by ?ukasz Langa in branch 'default':
Merged solution for #12036 from 3.2
http://hg.python.org/cpython/rev/2d984cc4afb0

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12036>
_______________________________________

From report at bugs.python.org  Mon May  9 18:56:28 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 May 2011 16:56:28 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304960188.14.0.566188148275.issue10666@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Sorry, I don't see how that could help.  The point I was making is that the directives accepted by GNU readline and BSD editline are completely different and one way or another the user is forced to deal with that.  If you used read_init_file, you would still need two different files anyway, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Mon May  9 19:06:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 May 2011 17:06:37 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304960797.15.0.858767542488.issue12015@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, you mean the security risk if the temporary names can be guessed? My recollection is that it is more of a problem for temporary directories than it is for temporary files, since the module can't control how files inside a temp directory get created. It's been a long time since I read anything detailed on the threat models and attack scenarios mkstemp() and friends were designed to handle though, so Google may be a better source of answers on that front.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 19:11:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 May 2011 17:11:11 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304961071.99.0.221206081101.issue10666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, I thought that read_init_file used a different filename with libedit.

Would there be a downside in implementing your suggestion labeled trivial, i.e. always use readline?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Mon May  9 19:35:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 May 2011 17:35:46 +0000
Subject: [issue5114] 2.7:  test_threading hangs on Solaris
In-Reply-To: <1233347094.1.0.608806299681.issue5114@psf.upfronthosting.co.za>
Message-ID: <1304962546.39.0.10901227525.issue5114@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hmm.
I think this was probably fixed by Gregory in issue #6643 (it's not in Python 2.7.1).
Could you try with Python 3.2, or a current snapshot?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5114>
_______________________________________

From report at bugs.python.org  Mon May  9 19:36:40 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 May 2011 17:36:40 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304962600.08.0.0993262737668.issue10666@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Even if used a different file name, you still have to set up two different sets of directives.

The main drawback to the trivial suggestion is that it continues to pull in GNU readline, which is now GPLv3-licensed, into the python.org OS X installers. In general, we try to avoid shipping GPL-licensed software since it can complicate the allowable usages of the installed Python.

(Since I opened this one, I'm reassigning it to myself.)

----------
assignee: ronaldoussoren -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Mon May  9 19:43:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 May 2011 17:43:49 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304963029.51.0.263393004655.issue10666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Even if used a different file name, you still have to set up two
> different sets of directives.

I was assuming this would not be a problem: the .inputrc (or hypothetical .editrc file) is written once for all applications, it?s not a Python-specific task.  What I didn?t see is that users do not necessarily know about which file is used, so it?s at least a doc problem.

For the perceived problem with licensing, I?m adding Martin to nosy, not because he?s a PSF director but because he?s had to make similar choices for the Windows installers.

Martin, here?s the context: the Mac installer sometimes builds readline with the real readline or libedit.  There?s a doc problem which can be solved either by always using the same lib.  The easiest to implement now would be choosing readline, but Ned says: ?The main drawback to the trivial suggestion is that it continues to pull in GNU readline, which is now GPLv3-licensed, into the python.org OS X installers. In general, we try to avoid shipping GPL-licensed software since it can complicate the allowable usages of the installed Python.?  Could you provide advice?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Mon May  9 19:54:15 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 09 May 2011 17:54:15 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304963655.46.0.255719825102.issue11948@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

What about the attached (v3) patch? the "This allows...experts hands." part can be remove completely if can be mis-interpreted.

----------
Added file: http://bugs.python.org/file21944/issue11948-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Mon May  9 19:59:44 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 May 2011 17:59:44 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304963984.29.0.0386696299137.issue10666@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

??ric, Martin was involved in the earlier discussions when the support for editline was originally added to the readline module.  We've been over this ground before.  See Issue6872 and Issue6877.

There are a number of options here.  I plan to investigate the supplying editline with the older installer variant.  That fits in with some other installer improvements that I'm working on.  I would prefer to defer further discussion on this issue until I've had a chance to further pursue that option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Mon May  9 20:00:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 May 2011 18:00:46 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The FreeBSD-AMD64 bot shows an error in test_logging:

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/243/steps/test/logs/stdio

Exception in thread Thread-281:
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 690, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_logging.py", line 726, in serve_forever
    asyncore.loop(poll_interval, map=self.sockmap)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/asyncore.py", line 214, in loop
    poll_fun(timeout, map)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/asyncore.py", line 144, in poll
    r, w, e = select.select(r, w, e, timeout)
select.error: (9, 'Bad file descriptor')

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/logging/handlers.py", line 1053, in emit
    h.getresponse()    #can't do anything with the result
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 316, in _read_status
    raise BadStatusLine(line)
http.client.BadStatusLine: ''
Logged from file test_logging.py, line 1493
/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/logging/__init__.py:837: ResourceWarning: unclosed <socket.socket object, fd=6, family=2, type=1, proto=6>
  self.emit(record)
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/logging/handlers.py", line 1053, in emit
    h.getresponse()    #can't do anything with the result
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/http/client.py", line 316, in _read_status
    raise BadStatusLine(line)
http.client.BadStatusLine: ''
Logged from file test_logging.py, line 1493

----------
components: Tests
messages: 135622
nosy: skrah, vinay.sajip
priority: normal
severity: normal
status: open
title: test_logging: bad file descriptor on FreeBSD bot
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 20:01:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 May 2011 18:01:58 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304964118.36.0.382169208794.issue12039@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 20:39:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 18:39:23 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>
Message-ID: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch exposes a new read-only property of multiprocessing.Process objects, named "sentinel".
As the doc indicates, this is a file descriptor undex Unix, and a handle under Windows. Both are suitable for flexible polling/waiting with the appropriate OS primitives. They become ready when the process has ended.
Under Unix, this also replaces the repeated polling in _Popen.wait() (called from Process.join()) with a regular select() call, making it friendlier with CPU low-power states.

This is necessary for issue9205.

----------
components: Library (Lib)
files: process_sentinel.patch
keywords: patch
messages: 135623
nosy: asksol, brian.curtin, gregory.p.smith, jnoller, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Expose a Process.sentinel property (and fix polling loop in Process.join())
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21945/process_sentinel.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12040>
_______________________________________

From report at bugs.python.org  Mon May  9 20:40:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 18:40:43 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1304966443.91.0.861808231291.issue9205@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Part of the patch submitted standalone in issue12040.

----------
dependencies: +Expose a Process.sentinel property (and fix polling loop in Process.join())

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Mon May  9 20:46:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 May 2011 18:46:15 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

It doesn't matter which order test_os and test_ctypes run in, but if they precede test_wait3 test_wait3 will fail.  When the test is immediately re-run it passes.

The reason ought to be interesting once we figure it out :)

Tested on linux.  Doesn't appear to affect other branches.

[1/3] test_os
[2/3] test_ctypes
[3/3] test_wait3
test test_wait3 failed -- Traceback (most recent call last):
  File "/home/rdmurray/python/p33/Lib/test/fork_wait.py", line 72, in test_wait
    self.wait_impl(cpid)
  File "/home/rdmurray/python/p33/Lib/test/test_wait3.py", line 30, in wait_impl
    self.assertEqual(spid, cpid)
AssertionError: 14480 != 14487

----------
keywords: buildbot
messages: 135625
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_os test_ctypes test_wait3 causes test_wait3 error
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 20:48:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 May 2011 18:48:32 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304966912.39.0.0203509557684.issue12041@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/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 20:55:17 2011
From: report at bugs.python.org (Davi Post)
Date: Mon, 09 May 2011 18:55:17 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>


New submission from Davi Post <post at pobox.com>:

In this section:
http://docs.python.org/whatsnew/2.6.html#pep-371-the-multiprocessing-package

This sentence follows the first example:
"A Queue is used to communicate the input parameter N and the result."

In the example, the queue is used only for the result, not the input parameter N.

[P.S. I'd be happy to submit corrections, but don't want to have to install and learn Mercurial. Is there a simpler way?]

----------
assignee: docs at python
components: Documentation
messages: 135626
nosy: davipo, docs at python
priority: normal
severity: normal
status: open
title: What's New multiprocessing example error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Mon May  9 20:55:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 May 2011 18:55:30 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304967330.3.0.902718116401.issue11948@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please don't make these kind of changes.  Guido has been clear that the docs need to affirmatively state what the language does.  

Except for certain security risks or segfault risks, the docs should avoid wording along the lines of "feature x is dangerous" or "experts only".  These kind of value judgements belong in blogs and wikis, not in the core documentation which should simply focus on what the language does and examples of how to use it effectively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Mon May  9 20:59:05 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 09 May 2011 18:59:05 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

This issue is to keep track of the 'shutil' documentation update, since it seems to miss several information (in particular in comparison with the docstrings).

I'll post patches as soon as I get them.

----------
assignee: docs at python
components: Documentation
messages: 135628
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: needs patch
status: open
title: Update shutil documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Mon May  9 21:05:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 09 May 2011 19:05:12 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304967912.47.0.261655116267.issue11948@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sorry Raymond for the bad editing, I was confused by thinking 'tutorial' is particularly meant for new-coming people. Anyhow, sorry again: I attach a patch removing the badworded part.

Please let me know if anything else is missing or needs fixing.

Thanks for your check & time.

----------
Added file: http://bugs.python.org/file21946/issue11948-v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Mon May  9 21:08:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 May 2011 19:08:53 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304968133.42.0.6854950652.issue11948@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Raymond: I haven't read the examples in detail so I don't have an opinion on the appropriateness of the text, but I'm curious: while what you say certainly applies to the Language Reference, does it also apply to the Tutorial?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Mon May  9 21:12:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 19:12:01 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304968321.23.0.913532789954.issue12041@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What seems to happen is that test_ctypes runs a lot of ldconfig processes, and the 10 retries in fork_wait are not enough to consume them all.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 21:13:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 May 2011 19:13:00 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304968380.4.0.703850262287.issue11948@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The tutorial is meant for newcomers.  The experience needs to be positive and not leave the reader with worries that something bad will happen if they make a misstep.

People commonly use the tutorial to evaluate the language as a whole.  The tutorial needs to show people what the language is capable of doing.  It should not create the impression that all its features are dangerous and should only be used by experts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Mon May  9 21:16:31 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 09 May 2011 19:16:31 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304968591.64.0.526907127305.issue12041@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/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 21:17:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 19:17:26 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <E1QJVxN-0004P8-4p@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9e473917cbfb by Antoine Pitrou in branch 'default':
Issue #12041: Make test_wait3 more robust.
http://hg.python.org/cpython/rev/9e473917cbfb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 21:19:32 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 May 2011 19:19:32 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304968772.47.0.445339267356.issue11948@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One other stylistic note.  The tone of the tutorial (and all the docs) needs to be respectful of the readers intelligence.  We don't presume that the readers are stupid.  We lay out the relevant information, show motivating use cases, provide glossary links, and do our best to connect-the-dots, but don't talk down them or waste their time.

The recent doc patch for using the in-operator instead of str.find borders on the edge of not giving readers credit for being able to make trivial inferences about the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Mon May  9 21:24:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 19:24:15 +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: <1304969055.59.0.685744558647.issue12044@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I find it a bit strange that Popen.__exit__ closes all standard file descriptors leading to the child process, but doesn't wait for process end afterwards.
(context management support was added in issue10554)

----------
messages: 135635
nosy: brian.curtin, gregory.p.smith, neologix, pitrou
priority: normal
severity: normal
status: open
title: subprocess.Popen.__exit__ doesn't wait for process end
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Mon May  9 21:25:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 19:25:20 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304969120.55.0.355989940616.issue12041@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This should be fixed, can you confirm?

PS: I've opened issue12044 as one of the root causes.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 21:35:14 2011
From: report at bugs.python.org (Alex Lai)
Date: Mon, 09 May 2011 19:35:14 +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: <1304969714.13.0.71851139877.issue12013@psf.upfronthosting.co.za>


Alex Lai <alex_lai at scotiacapital.com> added the comment:

I've installed it successfully on another server. That is enough. I haven't got time to upgrade my workstation from s10 pre-release to latest s10 release yet.


Thanks for the information,

Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Mon May  9 22:19:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 May 2011 20:19:58 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304972398.02.0.587931998808.issue12041@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Works for me after the commit.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 22:21:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 09 May 2011 20:21:11 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304972471.26.0.241235270133.issue12041@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12041>
_______________________________________

From report at bugs.python.org  Mon May  9 22:29:38 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 09 May 2011 20:29:38 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304972978.03.0.226287431607.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've made recent changes in test_logging to improve coverage, but these errors were not being raised on my local development machine (Ubuntu Jaunty). They have recently started occurring on my machine, too, so at the moment I'm suspecting some other change which is causing an interaction with test_logging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 22:32:33 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 09 May 2011 20:32:33 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304973153.32.0.876961368701.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've attached a smaller script which shows up the error. It's not tiny, but tests the SMTP and HTTP handler tests which show the failures mentioned in Stefan's post.

----------
Added file: http://bugs.python.org/file21947/server_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 22:41:04 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 09 May 2011 20:41:04 +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: <1304973664.85.0.760969463488.issue12044@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Seems like it would be enough to add a wait() at the end?

diff -r 9e473917cbfb Lib/subprocess.py
--- a/Lib/subprocess.py Mon May 09 21:17:02 2011 +0200
+++ b/Lib/subprocess.py Mon May 09 15:30:02 2011 -0500
@@ -796,6 +796,7 @@
             self.stderr.close()
         if self.stdin:
             self.stdin.close()
+        self.wait()

     def __del__(self, _maxsize=sys.maxsize, _active=_active):
         if not self._child_created:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Mon May  9 22:42:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 20:42:16 +0000
Subject: [issue12044] subprocess.Popen.__exit__ doesn't wait for process end
In-Reply-To: <1304973664.85.0.760969463488.issue12044@psf.upfronthosting.co.za>
Message-ID: <1304973733.3578.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Seems like it would be enough to add a wait() at the end?

Probably, perhaps with a try/finally?

I'm not entirely sure this is a good idea, by the way. May there be some
drawbacks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Mon May  9 22:45:55 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 May 2011 20:45:55 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1304973955.81.0.207852004383.issue10666@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's true that we should try to avoid distributing GPL'ed code with binary installers. At a minimum, we would have to provide the source of readline for download also, and we would have to warn anybody redistributing our binaries that they must include the source of readline and Python on the distribution media. So it's better to link against libedit, I'd say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Mon May  9 22:49:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 20:49:23 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304974163.64.0.22862236848.issue12015@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If you care about security, you should not use the Python random module because it is not cryptographic. Oh oh, ssl doesn't expose RAND_bytes().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 22:51:08 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 09 May 2011 20:51:08 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304974268.87.0.219503128006.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The rest isn't actually failing - it's just that a spurious BadStatusLine exception appears to be being raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 22:54:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 20:54:15 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304974163.64.0.22862236848.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304974452.3578.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If you care about security, you should not use the Python random
> module because it is not cryptographic. Oh oh, ssl doesn't expose
> RAND_bytes().

Feel free to open a separate issue and even provide a patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Mon May  9 23:01:56 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 09 May 2011 21:01:56 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304974916.55.0.0167149958885.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The change which causes the apparently spurious messages is one made by Senthil: 25298224cb25 - with the earlier revision 1ac03e071d65 the messages don't occur, as you can see here:

vinay at eta-jaunty:~/projects/python/default$ hg update -r 69980
merging Lib/test/test_logging.py
5 files updated, 1 files merged, 0 files removed, 0 files unresolved
vinay at eta-jaunty:~/projects/python/default$ python3.3 Lib/test/regrtest.py test_logging
[1/1] test_logging
1 test OK.
[131048 refs]
vinay at eta-jaunty:~/projects/python/default$ hg update -r 69981
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
vinay at eta-jaunty:~/projects/python/default$ python3.3 Lib/test/regrtest.py test_logging
[1/1] test_logging
Traceback (most recent call last):
  File "/home/vinay/projects/python/default/Lib/logging/handlers.py", line 1053, in emit
    h.getresponse()    #can't do anything with the result
  File "/home/vinay/projects/python/default/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/home/vinay/projects/python/default/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/home/vinay/projects/python/default/Lib/http/client.py", line 316, in _read_status
    raise BadStatusLine(line)
http.client.BadStatusLine: ''
Logged from file test_logging.py, line 1484
/home/vinay/projects/python/default/Lib/logging/__init__.py:837: ResourceWarning: unclosed <socket.socket object, fd=4, family=2, type=1, proto=6>
  self.emit(record)
Traceback (most recent call last):
  File "/home/vinay/projects/python/default/Lib/logging/handlers.py", line 1053, in emit
    h.getresponse()    #can't do anything with the result
  File "/home/vinay/projects/python/default/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/home/vinay/projects/python/default/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/home/vinay/projects/python/default/Lib/http/client.py", line 316, in _read_status
    raise BadStatusLine(line)
http.client.BadStatusLine: ''
Logged from file test_logging.py, line 1484
/home/vinay/projects/python/default/Lib/logging/__init__.py:837: ResourceWarning: unclosed <socket.socket object, fd=4, family=2, type=1, proto=6>
  self.emit(record)
1 test OK.
[131005 refs]

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 23:02:25 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 09 May 2011 21:02:25 +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: <1304974945.74.0.749679533148.issue12044@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Actually, I don't think the wait() is a good idea. If you want to block and infinitely wait on the process to close, you should do so explicitly.

It's probably better that we try to use terminate() or kill() and raise if that fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Mon May  9 23:05:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 21:05:15 +0000
Subject: [issue12044] subprocess.Popen.__exit__ doesn't wait for process end
In-Reply-To: <1304974945.74.0.749679533148.issue12044@psf.upfronthosting.co.za>
Message-ID: <1304975112.3578.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Actually, I don't think the wait() is a good idea. If you want to
> block and infinitely wait on the process to close, you should do so
> explicitly.

Ok.

> It's probably better that we try to use terminate() or kill() and raise if that fails.

Uh, I think it's worse. Using a context manager shouldn't do something
potentially destructive like killing a process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Mon May  9 23:09:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 21:09:07 +0000
Subject: [issue12045] external shell command executed twice in
	ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It seems `cmd` is executed twice, for no obvious reason, in the following code:
http://hg.python.org/cpython/file/2d4ef202d4ed/Lib/ctypes/util.py#l129

----------
components: Library (Lib)
messages: 135650
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: external shell command executed twice in ctypes.util._get_soname
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Mon May  9 23:10:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 May 2011 21:10:28 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1304953264.04.0.205589524384.issue8498@psf.upfronthosting.co.za>
Message-ID: <BANLkTin=oLgf3DGugUdh_Muao5U8+jOt4g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The patch looks fine to me: you just need to find someone interested
in reviewing and committing it (didn't find anyone listed as expert
for the socket module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Mon May  9 23:11:28 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 09 May 2011 21:11:28 +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: <1304975488.09.0.00942830897071.issue12044@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Hm, yeah, not sure what I was thinking there.

I'm thinking there's not a lot we can do here, but also not a lot that we should do here. We don't want to wait, and we don't want to close, so maybe we should just document that the usage should be limited only to expecting the open handles to be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Mon May  9 23:32:13 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 May 2011 21:32:13 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304976733.32.0.616387683905.issue12039@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

We might have two issues here. On FreeBSD the select.error occurs
reliably starting with r69723 (when the tests were added):

[buildbot at freebsd-amd64 /usr/home/buildbot/cpython]$ ./python -m test -uall test_logging
[1/1] test_logging
/usr/home/buildbot/cpython/Lib/logging/handlers.py:475: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>
  self.retryTime = now + self.retryPeriod
/usr/home/buildbot/cpython/Lib/logging/handlers.py:475: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>
  self.retryTime = now + self.retryPeriod
Exception in thread Thread-9:
Traceback (most recent call last):
  File "/usr/home/buildbot/cpython/Lib/threading.py", line 737, in _bootstrap_inner
    self.run()
  File "/usr/home/buildbot/cpython/Lib/threading.py", line 690, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/cpython/Lib/test/test_logging.py", line 667, in serve_forever
    asyncore.loop(poll_interval, map=self.sockmap)
  File "/usr/home/buildbot/cpython/Lib/asyncore.py", line 214, in loop
    poll_fun(timeout, map)
  File "/usr/home/buildbot/cpython/Lib/asyncore.py", line 144, in poll
    r, w, e = select.select(r, w, e, timeout)
select.error: (9, 'Bad file descriptor')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 23:34:17 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 May 2011 21:34:17 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304976857.85.0.964795417049.issue12039@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Maybe this link to the revision works: 2ab07776510c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Mon May  9 23:36:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 May 2011 21:36:34 +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: <1304976994.14.0.502934856435.issue11877@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Steffen, you changed the default to doing a "full sync" in your last patch: while I was favoring that initially, I now agree with Ronald and Antoine, and think that we shouldn't change the default behaviour. The reason being that Apple and NetBSD folks should know what they're doing, and that there might be some subtle side effects (see for example my comment on sync_file_range on Linux). Also, given how many bugs you seem to encouter on OS-X, it's probably better to stick to a syscall known to be safe instead of silently replacing it by a maybe-not-so-tested syscall. Finally, depending on the workload, it could have a significant performance impact. People requiring write durability will probably manage to find this full_sync parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Mon May  9 23:39:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 09 May 2011 21:39:23 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304977163.65.0.323323966041.issue11948@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Raymond, thanks for explaining the reasoning behind your replies, it really helps me understand the "spirit" behind python :)

That said, and trying to be a bit more pragmatical, what are the next steps to make this patch acceptable? It's kinda of a small patch, and I honestly didn't foresee the long ping-pong of corrections I received :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Mon May  9 23:40:51 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 09 May 2011 21:40:51 +0000
Subject: [issue12038] assertEqual doesn't display newline differences quite
	well
In-Reply-To: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>
Message-ID: <1304977251.62.0.646267115899.issue12038@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Yup, I agree that's pretty sucky. Any suggestions for a fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12038>
_______________________________________

From report at bugs.python.org  Mon May  9 23:47:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 21:47:28 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>
Message-ID: <1304977648.85.0.0302162654333.issue12040@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/issue12040>
_______________________________________

From report at bugs.python.org  Mon May  9 23:54:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 21:54:11 +0000
Subject: [issue11349] _pickle should implement the module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1304978051.08.0.753867312159.issue11349@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/issue11349>
_______________________________________

From report at bugs.python.org  Tue May 10 00:00:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 May 2011 22:00:40 +0000
Subject: [issue12044] subprocess.Popen.__exit__ doesn't wait for process end
In-Reply-To: <1304975488.09.0.00942830897071.issue12044@psf.upfronthosting.co.za>
Message-ID: <1304978437.3578.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm thinking there's not a lot we can do here, but also not a lot that
> we should do here. We don't want to wait, and we don't want to close,
> so maybe we should just document that the usage should be limited only
> to expecting the open handles to be closed?

Sounds good indeed :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Tue May 10 00:21:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 22:21:52 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <E1QJYpp-0006TI-KV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fa3227c3cf87 by Victor Stinner in branch '3.1':
Issue #1195: Fix input() if it is interrupted by CTRL+d and then CTRL+c,
http://hg.python.org/cpython/rev/fa3227c3cf87

New changeset b5914bfb4d04 by Victor Stinner in branch '3.2':
Issue #1195: Fix input() if it is interrupted by CTRL+d and then CTRL+c, clear
http://hg.python.org/cpython/rev/b5914bfb4d04

New changeset 3ff5d28ab630 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #1195: Fix input() if it is interrupted by CTRL+d and then
http://hg.python.org/cpython/rev/3ff5d28ab630

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 10 00:23:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 22:23:29 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <E1QJYrQ-0006Y9-8U@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c9f07c69b138 by Victor Stinner in branch '2.7':
(Merge 3.1) Issue #1195: Fix input() if it is interrupted by CTRL+d and then
http://hg.python.org/cpython/rev/c9f07c69b138

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 10 00:24:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 22:24:39 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1304979879.44.0.0812621839147.issue1195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It should be fixed. Reopen the issue if it doesn't work, I only tested on Linux.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 10 00:41:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 May 2011 22:41:22 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304980882.45.0.903321365653.issue11948@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sandro, import is a somewhat dark corner of Python that newcomers and even experienced people ofter trip over. So getting the text both correct and clear is worth some thought.

I just noticed that the text is only true for Python-coded modules and not for built-in modules. I discovered this by setting sys.path to {} and importing itertools. It works. It appears that Python first searches for builtins -- I created itertools.py and it did not mask the builtin. If there were a Lib/itertools.py which imported _itertools, it would have been masked. So it appears that the text should begin

"When a module named :mod:`spam` is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file ..."

I suggest changing
"This allows Python programs to modify or replace the module search path."
to
"After initialization, Python programs can modify sys.path."

and changing the followup

" Note that because the directory containing the script being run is on the search path, it is important that the script not have the same name as a standard module, or Python will attempt to load the script as a module when that module is imported.  This will generally be an error."

to something more like

"Because the directory containing the script being run is placed at the beginning of the search path, ahead of the standard library path, the script and other scripts in that directory should not have the same name as a standard library module unless one really intends for the script to be loaded in place of the standard library module."

or perhaps

"The directory containing the script being run is placed at the beginning of the search path, ahead of the standard library path. This means that scripts in that directory will be loaded instead of modules of the same name in the library directory. This is an error unless the replacement is intended."

I think the change to warn about all possibly conflicting scripts in the directory is needed because a common problem people have is more like

import random
a = random.choice('abc')

raising AttributeError ("O python-list, why???") because there is a forgotten random.py in the same directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Tue May 10 00:50:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 22:50:09 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <E1QJZHC-0008WT-5D@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b7abf0590e1c by Victor Stinner in branch '3.1':
Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional
http://hg.python.org/cpython/rev/b7abf0590e1c

New changeset 20beec22764f by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional
http://hg.python.org/cpython/rev/20beec22764f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Tue May 10 01:04:15 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 May 2011 23:04:15 +0000
Subject: [issue12046] Windows build identification incomplete
In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>
Message-ID: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The Unix build identifies itself with a string such as

Python 3.2.1b1 (3.2:5b34f84ca773, May 10 2011, 00:58:43)

and sys._mercurial then is ('CPython', '3.2', '5b34f84ca773')

In the Windows build, the identification is

Python 3.2.1b1 (default, May 10 2011, 00:33:43) [MSC v.1500 32 bit (Intel)] on win32

and sys._mercurial is ('CPython', '', '')

Not sure whether this is a release blocker, but it's definitely a step backwards from 3.2.0.

----------
messages: 135664
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Windows build identification incomplete
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12046>
_______________________________________

From report at bugs.python.org  Tue May 10 01:08:39 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 09 May 2011 23:08:39 +0000
Subject: [issue12046] Windows build identification incomplete
In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>
Message-ID: <1304982519.65.0.438906152395.issue12046@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/issue12046>
_______________________________________

From report at bugs.python.org  Tue May 10 01:45:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 09 May 2011 23:45:26 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304984726.56.0.535027833573.issue12039@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I could reproduce the BadStatusLine exception using Vinay's server_test.py. I see that the exception is triggered by logging package when it is trying to http.client's getresponse() before it is ready. The previous commit 25298224cb25 was on http.server (client code was not involved) and surprised at how it could be a trigger. Shall provide updates after further investigation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 01:52:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2011 23:52:30 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <E1QJaFY-000460-O7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3c87a13980be by Victor Stinner in branch '2.7':
(Merge 3.1) Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional
http://hg.python.org/cpython/rev/3c87a13980be

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Tue May 10 01:52:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 May 2011 23:52:36 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304985156.5.0.429085428316.issue11948@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Raymond: yes, thanks for the clear guidance.  Perhaps it could be added to Documenting Python, perhaps in the Style Guide chapter?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Tue May 10 01:53:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 May 2011 23:53:29 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1304985209.4.0.225586317243.issue12012@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Since it's a bugfix, it should probably go into all branches.

Fixed in 2.7, 3.1, 3.2, 3.3.

----------
resolution:  -> fixed
status:  -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Tue May 10 01:57:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 May 2011 23:57:54 +0000
Subject: [issue12041] test_os test_ctypes test_wait3 causes test_wait3 error
In-Reply-To: <1304966775.11.0.623778151343.issue12041@psf.upfronthosting.co.za>
Message-ID: <1304985474.05.0.860883092315.issue12041@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Confirmed working on my box as well, and on my buildbot (where I first noticed it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12041>
_______________________________________

From report at bugs.python.org  Tue May 10 01:58:16 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 09 May 2011 23:58:16 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1304985496.14.0.539031625384.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Ok, I'll leave the BadStatusLine problem for Senthil to investigate. I have reproduced the problem with the SMTP server on FreeBSD, but this problem does not occur on Linux and I'm not sure why it would fail on FreeBSD.

I've attached a script, smtp_test.py, which does not involve logging code at all, just smtpd, smtplib and other support code. This runs without errors on Linux (Ubuntu Jaunty) and Windows 7 but fails with "bad file descriptor" on my test machine running FreeBSD 8 (32-bit).

Added Giampaolo to nosy as he may be able to spot the problem.

----------
nosy: +giampaolo.rodola
Added file: http://bugs.python.org/file21948/smtp_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 02:03:56 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 10 May 2011 00:03:56 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1304985836.67.0.912653150034.issue1195@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

The patch still does not handle the case where the eof indicator is already set when calling raw_input. My original patch does.

Run the following program and hit ctrl-d, then ctrl-c:

import sys
sys.stdin.read()

while True:
    try:
        s = raw_input('> ')
    except:
        pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 10 03:06:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 01:06:34 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1304989594.63.0.6021328237.issue1195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch still does not handle the case where the eof indicator
> is already set when calling raw_input. My original patch does.

Correct, your example fails, but only in Python 2.7. I don't like the idea of always clearing errors. I prefer to reset stdin only after an error or EOF. Attached patch changes file.read() to clear the EOF flag if the read was stopped because of the EOF.

----------
Added file: http://bugs.python.org/file21949/clear_eof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 10 03:11:02 2011
From: report at bugs.python.org (Philip Semanchuk)
Date: Tue, 10 May 2011 01:11:02 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1304989862.16.0.934322863256.issue8426@psf.upfronthosting.co.za>


Changes by Philip Semanchuk <osvenskan at users.sourceforge.net>:


----------
nosy: +osvenskan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Tue May 10 03:12:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 May 2011 01:12:35 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1304989955.36.0.436682836932.issue11948@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with both Raymond and David's suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Tue May 10 03:49:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 May 2011 01:49:50 +0000
Subject: [issue12026] Support more of MSI api
In-Reply-To: <1304743825.08.0.890355737934.issue12026@psf.upfronthosting.co.za>
Message-ID: <1304992190.89.0.87207595442.issue12026@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Your title mixes a goal -- exposing more of the MSI api -- with a particular means -- exposing an object that is only useful with ctypes. So I have taken the liberty of removing the implementation limitation. While clever, I do not believe that strategy has any precedent in the stdlib. While the stdlib includes ctypes, it does not use it to implement functions. While your proposal does not directly use ctypes, it does indirectly, by proxy (the user). So I think wider discussion, perhaps on pydev or python-idea, to see where the proposal falls with respect to current policy, before it could be approved. A special feature of msilib is that it is Windows only, where ctypes *should* always be available (though even that is not guaranteed if there is no maintenance, which there mostly is not at present).

Martin's suggestion is the traditional path. I have 0 knowledge of MSI API. How many new functions are we talking about? 10? 100?

----------
nosy: +terry.reedy
title: Support more of MSI api by exposing handles -> Support more of MSI api

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12026>
_______________________________________

From report at bugs.python.org  Tue May 10 04:28:22 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 10 May 2011 02:28:22 +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: <1304994502.26.0.0380016504587.issue12044@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Looks like we already mention that.

"""
Popen objects are supported as context managers via the with statement, closing any open file descriptors on exit.
"""

Antoine, do you think this should be more strongly worded?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Tue May 10 04:30:21 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 10 May 2011 02:30:21 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1304994621.54.0.0502480593624.issue1625@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
nosy: +nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Tue May 10 04:30:36 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 10 May 2011 02:30:36 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1304994636.44.0.0776259227331.issue9504@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
nosy: +nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________

From report at bugs.python.org  Tue May 10 04:30:51 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 10 May 2011 02:30:51 +0000
Subject: [issue11743] Rewrite PipeConnection and Connection in pure Python
In-Reply-To: <1301779980.98.0.515045950536.issue11743@psf.upfronthosting.co.za>
Message-ID: <1304994651.92.0.779717646813.issue11743@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
nosy: +nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11743>
_______________________________________

From report at bugs.python.org  Tue May 10 04:32:01 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 10 May 2011 02:32:01 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1304994721.74.0.0501251062974.issue9971@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
nosy: +nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue May 10 04:32:27 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 10 May 2011 02:32:27 +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: <1304994747.79.0.361733494755.issue6721@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
nosy: +nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue May 10 04:54:07 2011
From: report at bugs.python.org (Steve Ward)
Date: Tue, 10 May 2011 02:54:07 +0000
Subject: [issue12015] possible characters in temporary file name is too few
In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za>
Message-ID: <1304996047.78.0.897549558933.issue12015@psf.upfronthosting.co.za>


Changes by Steve Ward <planet36 at gmail.com>:


Added file: http://bugs.python.org/file21950/tempfile.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12015>
_______________________________________

From report at bugs.python.org  Tue May 10 06:46:52 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 10 May 2011 04:46:52 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305002812.92.0.238253737378.issue11948@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1 to the guidance, and to adding it to the doc style chapter.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Tue May 10 07:28:39 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 10 May 2011 05:28:39 +0000
Subject: [issue10666] OS X installer variants have confusing readline
	differences
In-Reply-To: <1291931066.91.0.86480513545.issue10666@psf.upfronthosting.co.za>
Message-ID: <1305005319.86.0.365229588983.issue10666@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

FWIW I'm in favor of shipping libedit as well with the 32-bit variant of the installer. The installer for 10.6 can continue to use the system install, that's good enough for to be used.

The download link for the copy in OSX 10.6.7 is <http://opensource.apple.com/tarballs/libedit/libedit-13.tar.gz>, this is BSD licensed code that we can ship in the installer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10666>
_______________________________________

From report at bugs.python.org  Tue May 10 08:48:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 06:48:43 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <E1QJgkI-0005Vf-7J@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b365036b17c2 by Vinay Sajip in branch 'default':
Issue #12039: Now suppress spurious select.error raised on FreeBSD when the server (an asyncore.dispatcher) is closed.
http://hg.python.org/cpython/rev/b365036b17c2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 08:49:46 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 10 May 2011 06:49:46 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1305010186.18.0.0681965762507.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've done a bit more investigating, and the select.error is raised in the server thread when the main thread closes the SMTP server (asyncore.dispatcher). I've modified the server code to swallow the error if the server has been closed.

This closes the issue as far as the select.error is concerned - leaving open for Senthil's follow-up on BadStatusLine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 08:51:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 May 2011 06:51:18 +0000
Subject: [issue12047] Expand the style guide
Message-ID: <1305010277.63.0.0752663302866.issue12047@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: georg.brandl
components: Documentation
files: style.diff
keywords: patch
nosy: georg.brandl, rhettinger
priority: normal
severity: normal
status: open
title: Expand the style guide
Added file: http://bugs.python.org/file21951/style.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12047>
_______________________________________

From report at bugs.python.org  Tue May 10 08:58:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 May 2011 06:58:04 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305010684.61.0.369799580849.issue11948@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

See http://bugs.python.org/issue12047

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Tue May 10 08:58:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 10 May 2011 06:58:59 +0000
Subject: [issue12047] Expand the style guide
In-Reply-To: <1305010739.74.0.674416738144.issue12047@psf.upfronthosting.co.za>
Message-ID: <1305010739.74.0.674416738144.issue12047@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Sounds very good to me.

One small thing: in the first para of "Audience", there's a "talk down them" which looks funny to me in this word order.

One question: I could imagine wording like "this is rarely needed" instead of "this is experts only" -- would you say it will be effective in making people think if they really want to do that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12047>
_______________________________________

From report at bugs.python.org  Tue May 10 09:05:06 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 10 May 2011 07:05:06 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1305011106.96.0.563564166634.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Additional information point for Senthil: In the case where the BadStatusLine is raised, the server is sending a 200 OK status response but there is no actual response data - only headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 09:10:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 May 2011 07:10:17 +0000
Subject: [issue12047] Expand the style guide
In-Reply-To: <1305010739.74.0.674416738144.issue12047@psf.upfronthosting.co.za>
Message-ID: <1305011417.66.0.772709017381.issue12047@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> there's a "talk down them" which looks funny to me in this word order.

It was missing a word.  Should be "talk down to them".  Thanks for spotting this -- I fix it in the commit.

> One question: I could imagine wording like 
> "this is rarely needed" instead of "this is experts only" 
> -- would you say it will be effective in making people
> think if they really want to do that?

Something along these lines would be a step in the right direction (though "rarely needed" is problematic if happens to match the readers need at the moment).  At this point, I would be happy just to get rid of the danger-experts-only remarks.  Just about any substitute would be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12047>
_______________________________________

From report at bugs.python.org  Tue May 10 09:11:50 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 10 May 2011 07:11:50 +0000
Subject: [issue12047] Expand the style guide
In-Reply-To: <1305010739.74.0.674416738144.issue12047@psf.upfronthosting.co.za>
Message-ID: <1305011510.9.0.512455100238.issue12047@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

And I sincerely hope we don't have any docs that say "if you don't know what this is, you don't need it" instead of an explanation :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12047>
_______________________________________

From report at bugs.python.org  Tue May 10 09:36:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 07:36:45 +0000
Subject: [issue12047] Expand the style guide
In-Reply-To: <1305010739.74.0.674416738144.issue12047@psf.upfronthosting.co.za>
Message-ID: <E1QJhUq-0001Dn-56@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d5d91b14b238 by Raymond Hettinger in branch '3.2':
Issue 12047: Expand the style guide.
http://hg.python.org/cpython/rev/d5d91b14b238

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12047>
_______________________________________

From report at bugs.python.org  Tue May 10 09:39:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 07:39:12 +0000
Subject: [issue12047] Expand the style guide
In-Reply-To: <1305010739.74.0.674416738144.issue12047@psf.upfronthosting.co.za>
Message-ID: <E1QJhXC-0001Mp-Ra@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 50a5e271edf9 by Raymond Hettinger in branch '2.7':
Issue 12047: Expand the style guide.
http://hg.python.org/cpython/rev/50a5e271edf9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12047>
_______________________________________

From report at bugs.python.org  Tue May 10 09:39:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 May 2011 07:39:40 +0000
Subject: [issue12047] Expand the style guide
In-Reply-To: <1305010739.74.0.674416738144.issue12047@psf.upfronthosting.co.za>
Message-ID: <1305013180.81.0.130884400725.issue12047@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/issue12047>
_______________________________________

From report at bugs.python.org  Tue May 10 09:59:57 2011
From: report at bugs.python.org (yaoyu)
Date: Tue, 10 May 2011 07:59:57 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>


New submission from yaoyu <yao_yu at 126.com>:

Python 3, ZipFile Bug In Chinese:
1. In Python3.1.3 can't extract "?? test.txt" from test.zip
???? test.txt
Traceback (most recent call last):
  File "C:\Temp\PythonZipTest\pythonzip.py", line 14, in <module>
    main()
  File "C:\Temp\PythonZipTest\pythonzip.py", line 11, in main
    z.extract(z.namelist()[0])
  File "c:\python31\lib\zipfile.py", line 980, in extract
    return self._extract_member(member, path, pwd)
  File "c:\python31\lib\zipfile.py", line 1023, in _extract_member
    source = self.open(member, pwd=pwd)
  File "c:\python31\lib\zipfile.py", line 928, in open
    % (zinfo.orig_filename, fname))
zipfile.BadZipfile: File name in directory '???? test.txt' and header b'\xb8\xb4\xbc\xfe test.txt' differ.

2.  In Python3.2 extract "?? test.txt" from test.zip uncorrect
  It extract the file as "???? test.txt"

3. In Python 2.7.1, It's OK!

??????????2011-05-10
Source Code
######################################################################
#coding=gbk

import zipfile
import os

def main():
  szTestDir = os.path.dirname(__file__)
  szFile = os.path.join(szTestDir, 'test.zip')
  z = zipfile.ZipFile(szFile)
  print(z.namelist()[0])
  z.extract(z.namelist()[0])

if __name__ == '__main__':
  main()

----------
files: test.zip
messages: 135687
nosy: yaoyu
priority: normal
severity: normal
status: open
title: Python 3, ZipFile Bug In Chinese
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file21952/test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Tue May 10 10:10:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 08:10:11 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The _ssl module has RAND_add() RAND_status() and RAND_egd() functions, but not RAND_bytes(). I would be nice to be able to generate random bytes using RAND_bytes().

And maybe also RAND_pseudo_bytes()?

I will work on a patch, it's just a reminder.

----------
components: Library (Lib)
messages: 135688
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: expose RAND_bytes() function of OpenSSL
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Tue May 10 10:10:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 08:10:16 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <E1QJi1H-0003qh-8d@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 204e027dfa98 by Vinay Sajip in branch 'default':
Issue #12039: Add end_headers() call to avoid BadStatusLine.
http://hg.python.org/cpython/rev/204e027dfa98

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 11:09:23 2011
From: report at bugs.python.org (Jens Grivolla)
Date: Tue, 10 May 2011 09:09:23 +0000
Subject: [issue5752] xml.dom.minidom does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1305018563.4.0.580956465285.issue5752@psf.upfronthosting.co.za>


Changes by Jens Grivolla <jens.grivolla at gmail.com>:


----------
nosy: +Jens.Grivolla

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Tue May 10 11:11:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 May 2011 09:11:46 +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: <1305018706.44.0.0939325170617.issue12044@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, no, looks ok for me then :)

----------
resolution:  -> rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Tue May 10 11:12:58 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 10 May 2011 09:12:58 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1305018778.63.0.303156881029.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The errors seem to have gone away now, but there is still apparently a behaviour change - previously there was no error when a end_headers() call was omitted when handling a request, but now apparently an end_headers() call is needed to avoid the error.

Either omitting the end_headers() call was always an error but previously undetected, or the requirement to always call end_headers() is new and this should be documented. I'm not sure which of these is the case, but leaving open since I think the http.server documentation ought to be changed. Apart from this I think the issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 11:26:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 May 2011 09:26:13 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1304896386.11.0.128008274277.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305019569.3569.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Based on the above I think you are right about using the internal buffer
> regardless (revision attached). You pay a price with larger buffer sizes but on
> balance it seems to be a much better general purpose solution. The java-like 
> solution is decent as well, it is only slightly slower for small reads and optimal
> for larger buffer sizes.

Thanks for the measurements!
The way the loop is written is a bit quirky, can't the flow be made more
sequential:

+        if (n > 0) /* short circuit */
+           goto drain;
+        if (n == 0 || (n == -2 && written > 0))
+            break;
+        if (n == -2) {
+            Py_INCREF(Py_None);
+            res = Py_None;
+        }
+        goto end;

Also, it seems you don't have the unlocked fast path for small reads
anymore (when they can be serviced in whole from the buffer).

> Interestingly enough it seems like using read() is a better idea
> if you use a smaller size (how is that right?).

That's interesting indeed. Perhaps that is due to the overhead of
getting a Py_buffer to the readinto() argument. It would be nice to
optimize it, but it's probably outside the scope for this issue.

(it also shows that our allocator does quite well with small objects)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue May 10 11:30:04 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 10 May 2011 09:30:04 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1305019804.12.0.435691335808.issue1195@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Either you clearerr or you can't rely on feof. fgets might also set the end of file indicator *and* return valid data. I don't see a reason to not call clearerr right before trying to read from the stream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 10 11:36:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 May 2011 09:36:05 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305020165.78.0.0269023178834.issue9971@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, the Java-like version actually seems quite interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue May 10 11:52:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 May 2011 09:52:02 +0000
Subject: [issue12046] Windows build identification incomplete
In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>
Message-ID: <1305021122.14.0.523074863151.issue12046@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note, the Unix build only identifies itself like that if there is a working copy of hg on $PATH at configure time.  If not, the version string also silently defaults to "default".  That requirement creates a bit of a problem for the OS X installer build script since hg is not currently shipped with OS X and the build script goes to some lengths to ensure that the build environment is not contaminated with non-system components, including setting PATH to standard system values.  It might also be an issue for some other Unix platform builds.  My preference would be to add an AC_PATH_PROG check or some such to configure.in to be able to specify an HG environment variable rather than having to open up PATH.  Comments?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12046>
_______________________________________

From report at bugs.python.org  Tue May 10 12:07:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 May 2011 10:07:55 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1305018778.63.0.303156881029.issue12039@psf.upfronthosting.co.za>
Message-ID: <20110510100746.GA18370@kevin>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Tue, May 10, 2011 at 09:12:58AM +0000, Vinay Sajip wrote:
> Either omitting the end_headers() call was always an error but
> previously undetected, or the requirement to always call
> end_headers() is new and this should be documented. I'm not sure
> which of these is the case, but leaving open since I think the
> http.server documentation ought to be changed. Apart from this I

end_headers was added 3.2, so that all the headers can be cached and
sent at once instead of writing one header at a time to the output
stream. This is a new change in 3.3, where end_header calls
flush_header which does the job of writing and clearing the cache.

The need to call end_header always is new (at least from 3.2, because
I see the http.server code itself using end_header at the end whenever
it uses send_header)

Following is the information in the updated docs.

.. method:: send_header(keyword, value)

         Adds the HTTP header to an internal buffer which will be
         written to the output stream when either :meth:`end_headers`
         or :meth:`flush_headers` is invoked. 

I think, a little change in wording saying that end_headers or
flush_headers MUST BE called would make it more prominent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 12:44:15 2011
From: report at bugs.python.org (Takeshi Yoshino)
Date: Tue, 10 May 2011 10:44:15 +0000
Subject: [issue12050] unconsumed_tail of zlib.Decompress is not always cleared
	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>


New submission from Takeshi Yoshino <tyoshino at google.com>:

http://docs.python.org/library/zlib.html
says
"If max_length is not supplied then the whole input is decompressed, and unconsumed_tail is an empty string."

However, if there's preceding decompress call with max_length specified, unconsumed_tail will not be empty.

----
import zlib

c = zlib.compressobj(zlib.Z_DEFAULT_COMPRESSION, zlib.DEFLATED, -zlib.MAX_WBITS)
compressed = c.compress('abc')
compressed += c.flush(zlib.Z_SYNC_FLUSH)

d = zlib.decompressobj(-zlib.MAX_WBITS)
original = d.decompress(data, 1)
original += d.decompress(d.unconsumed_tail)
print "%r" % d.unconsumed_tail
----

Result is

----
'\x06\x00\x00\x00\xff\xff'
----

Document or code should be fixed.

----------
components: Library (Lib)
messages: 135697
nosy: Takeshi.Yoshino
priority: normal
severity: normal
status: open
title: unconsumed_tail of zlib.Decompress is not always cleared on decompress() call
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12050>
_______________________________________

From report at bugs.python.org  Tue May 10 13:01:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 11:01:55 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305025315.24.0.0643058254635.issue9971@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+    Py_SAFE_DOWNCAST(READAHEAD(self), Py_off_t, Py_ssize_t)

Why downcasting the size? Can't you store the size into a Py_off_t? I suppose that sizeof(Py_off_t) >= sizeof(Py_ssize_t).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue May 10 13:59:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 10 May 2011 11:59:58 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1304976994.14.0.502934856435.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110510115934.GA23147@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I don't agree with you and i don't believe it is implemented like
that.  But it seems i am the only one on this issue who sees it
like that.  Thus i apply 11877.6.diff.

> Declaring variables as "auto" is not necessary in C code and not
> used anywhere else in Python's source code

Changed.

> Steffen, you changed the default to doing a "full sync" in your
> last patch

Changed all through.

> The reason being that Apple and NetBSD folks should know what
> they're doing [.]
> People requiring write durability will probably manage to find
> this full_sync parameter.

This sounds logical.  I've changed the doc in os.rst so that it
includes a note on *which* operating systems actually do something
dependend on that argument.
I should have done that from the very beginning.

> Finally, depending on the workload, it could have a significant
> performance impact.

:-)

----------
Added file: http://bugs.python.org/file21953/11877.6.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
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,13 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   The POSIX standart only 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.  On operating systems where it is
+   necessary and possible the optional *full_fsync* argument can be used to
+   initiate additional steps to synchronize the physical backing store.
+   At the time of this writing this affects Apple Mac OS X and NetBSD.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2121,13 +2121,46 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_fsync=False)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"full_fsync forces flush of disk caches in case fsync() alone is not enough.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    PyObject *fdobj;
+    int full_fsync = 0;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        return NULL;
+
+    /* See issue 11877 discussion */
+# if ((defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC))
+    if (full_fsync != 0) {
+        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__
+        res = fcntl(fd, F_FULLFSYNC);
+#  elif defined __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0)
+            return posix_error();
+        Py_INCREF(Py_None);
+        return Py_None;
+    } else
+# endif
+        return posix_fildes(fdobj, fsync);
 }
 #endif /* HAVE_FSYNC */
 
@@ -9472,7 +9505,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Tue May 10 15:55:44 2011
From: report at bugs.python.org (Jonathan Halcrow)
Date: Tue, 10 May 2011 13:55:44 +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: <1305035744.62.0.0175129808305.issue2636@psf.upfronthosting.co.za>


Jonathan Halcrow <jonathan.halcrow at gmail.com> added the comment:

I'm having a problem using the current version (0.1.20110504) with python 2.5 on OSX 10.5.  When I try to import regex I get the following import error:

dlopen(<snipped>/python2.5/site-packages/_regex.so, 2): Symbol not found: _re_is_same_char_ign
  Referenced from: <snipped>/python2.5/site-packages/_regex.so
  Expected in: dynamic lookup

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue May 10 16:06:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 May 2011 14:06:08 +0000
Subject: [issue1046092] HTMLParser fix to accept malformed tag attributes
Message-ID: <1305036368.17.0.651008518326.issue1046092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

For the record, the new issue is #12008.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1046092>
_______________________________________

From report at bugs.python.org  Tue May 10 16:06:48 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 10 May 2011 14:06:48 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1305036408.2.0.962540501898.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Senthil - are you planning to make the documentation change, or should I?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 16:07:02 2011
From: report at bugs.python.org (Jonathan Halcrow)
Date: Tue, 10 May 2011 14:07:02 +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: <1305036422.01.0.792443213677.issue2636@psf.upfronthosting.co.za>


Jonathan Halcrow <jonathan.halcrow at gmail.com> added the comment:

It seems that _regex_unicode.c is missing from setup.py, adding it to ext_modules fixes my previous issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue May 10 16:08:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 10 May 2011 14:08:44 +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: <1305036524.6.0.554932618531.issue2636@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Issues with Regexp should probably be handled on the Regexp tracker.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue May 10 16:10:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 May 2011 14:10:48 +0000
Subject: [issue11979] Minor improvements to the Sockets readme: typos,
	wording and sphinx features usage
In-Reply-To: <1304344252.29.0.0856006463682.issue11979@psf.upfronthosting.co.za>
Message-ID: <1305036648.09.0.251809826884.issue11979@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/issue11979>
_______________________________________

From report at bugs.python.org  Tue May 10 16:15:53 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 May 2011 14:15:53 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1305036408.2.0.962540501898.issue12039@psf.upfronthosting.co.za>
Message-ID: <20110510141511.GA2479@kevin>


Senthil Kumaran <senthil at uthcode.com> added the comment:

On Tue, May 10, 2011 at 02:06:48PM +0000, Vinay Sajip wrote:
> @Senthil - are you planning to make the documentation change, or should I?

I shall do it, Vinay.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Tue May 10 16:19:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 May 2011 14:19:28 +0000
Subject: [issue12011] The signal module should raise OSError for OS-related
	exceptions, not RuntimeError
In-Reply-To: <1304896183.96.0.225902888589.issue12011@psf.upfronthosting.co.za>
Message-ID: <1305037162.3569.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Patch: signal.signal() and signal.siginterrupt() raise an OSError,
> instead of a RuntimeError: OSError has an errno attribute.
> 
> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file21939/signal_oserror.patch

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12011>
_______________________________________

From report at bugs.python.org  Tue May 10 16:45:06 2011
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 10 May 2011 14:45:06 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1305038706.35.0.232088682441.issue1028@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Tcl/Tk uses modified utf-8 internally.  This includes using 0xC080, a multibyte Unicode null character, for embedded nulls that work with C's null terminated strings.  Java does the same.

Note that typing Ctrl-space and Ctrl-2 are conventional ways to enter a null from the keyboard.  That's the reason a null char is associated with those key combinations.

When Tcl exports Unicode, it is supposed to be strict utf-8.  Until Tcl8.5, the %A (Unicode character corresponding to an event) was incorrectly leaking the modified Unicode null.

_tkinter.c.2.patch is narrowly focused: if PythonCmd raises a UnicodeDecodeError and if the string passed in an arg is 0xC080, it is replaced with the Unicode null 0x00.

----------
assignee: ned.deily -> kbk
components: +Unicode
nosy: +kbk
resolution:  -> accepted
Added file: http://bugs.python.org/file21954/tkinter.c.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Tue May 10 17:05:53 2011
From: report at bugs.python.org (Ruben Van Boxem)
Date: Tue, 10 May 2011 15:05:53 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1305039953.53.0.41272055873.issue4709@psf.upfronthosting.co.za>


Ruben Van Boxem <vanboxem.ruben at gmail.com> added the comment:

Has anyone looked at this? I'm trying to build gdb with Python enabled with mingw-w64 (Python 2.7.1 with manually created import libraries), but have to manually define MS_WIN64 in the CFLAGS. The patch only does what's right (i.e. define a macro that should be defined). David has nicely explained what needs to be done to reproduce the issue.

Thanks!

----------
nosy: +rubenvb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Tue May 10 17:11:21 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 10 May 2011 15:11:21 +0000
Subject: [issue11959] smtpd cannot be used without affecting global state
In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za>
Message-ID: <1305040281.24.0.922497650904.issue11959@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The overridden create_socket() method will have the same behaviour for the case when a socket map is *not* passed in to smtpd.__init__(). Users using the existing signature for the constructor will cause the sockmap instance attribute to be set to None, and this will get passed in to set_socket just as was happening before. So the only time the overridden create_socket will behave differently is if a non-None value is passed into smtpd.__init__(), and that's by design.

Of course there is a slightly increased maintenance burden, in that other functional changes to asyncore.dispatcher.create_socket will need to be duplicated in smtpd.create_socket. However, such changes would be fairly infrequent, methinks. A comment could be added to asyncore.dispatcher.create_socket if necessary, to remind maintainers about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11959>
_______________________________________

From report at bugs.python.org  Tue May 10 17:15:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 15:15:05 +0000
Subject: [issue12011] The signal module should raise OSError for OS-related
	exceptions, not RuntimeError
In-Reply-To: <1304628580.22.0.561171702394.issue12011@psf.upfronthosting.co.za>
Message-ID: <E1QJoeN-0007Sq-S0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b86b39211ef1 by Victor Stinner in branch 'default':
Issue #12011: signal.signal() and signal.siginterrupt() raise an OSError,
http://hg.python.org/cpython/rev/b86b39211ef1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12011>
_______________________________________

From report at bugs.python.org  Tue May 10 17:24:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 15:24:25 +0000
Subject: [issue12011] The signal module should raise OSError for OS-related
	exceptions, not RuntimeError
In-Reply-To: <1304628580.22.0.561171702394.issue12011@psf.upfronthosting.co.za>
Message-ID: <1305041065.79.0.367124860228.issue12011@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/issue12011>
_______________________________________

From report at bugs.python.org  Tue May 10 17:51:26 2011
From: report at bugs.python.org (Waldemar Kornewald)
Date: Tue, 10 May 2011 15:51:26 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305042686.79.0.0996220331537.issue6727@psf.upfronthosting.co.za>


Waldemar Kornewald <wkornewald at gmail.com> added the comment:

Symlinked packages used to work on Windows until recently, but a few days ago Microsoft published a few security patches and things stopped working. On my local machine I uninstalled all Visual C++ Runtime library patches (they were installed automatically on May 5th) and symlinks started working on my machine, again. On my friend's computer symlinked packages suddenly stopped working today, but he doesn't seem to have the Visual C++ Runtime libs, so we don't know how to work around this issue on his computer. Could someone please fix support for symlinked packages? It's an essential feature during development.

----------
nosy: +wkornewald

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 17:53:57 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 10 May 2011 15:53:57 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305042837.47.0.0709674885988.issue6727@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Are you able to narrow it down to which security update(s) caused the breakage?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 18:01:38 2011
From: report at bugs.python.org (Waldemar Kornewald)
Date: Tue, 10 May 2011 16:01:38 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305043298.7.0.671004719933.issue6727@psf.upfronthosting.co.za>


Waldemar Kornewald <wkornewald at gmail.com> added the comment:

I uninstalled these three security patches:

* KB2467173: http://support.microsoft.com/kb/2467173
* KB2467174: http://support.microsoft.com/kb/2467174
* KB2467175: http://support.microsoft.com/kb/2467175

Without those patches symlinked packages work for me. I didn't try to narrow it down to the exact patch. Instead I uninstalled all Visual C++ Redistributable packages in order to prevent those patches from ever being installed again. Should I risk breaking symlink support again to find the source of the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 18:06:45 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 10 May 2011 16:06:45 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305043605.81.0.929064686378.issue6727@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Don't do anything you're not comfortable with. If you can get your system to whatever state it was in the past where things worked properly, feel free to dig into it. I will try to look into this situation and see if there's anything in these security updates that looks related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 18:08:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 10 May 2011 16:08:27 +0000
Subject: [issue12044] subprocess.Popen.__exit__ doesn't wait for process end
In-Reply-To: <1304994502.26.0.0380016504587.issue12044@psf.upfronthosting.co.za>
Message-ID: <BANLkTinRDu0_r7fNPT4Aov=GpCVFybm-4A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

There's just one thing I'm concerned with.
People using context managers tend to expect the __exit__ method to
perform cleanup actions and release corresponding resources if
necessary, for example closing the underlying file or socket.
So my guess is that most people won't explicitly wait for the process
termination. You can already find such examples inside
test_subprocess.py, Lib/ctypes/util.py (to parse ldconfig's output),
and even in subprocess' documentation:

"""
with Popen(["ifconfig"], stdout=PIPE) as proc:
    log.write(proc.stdout.read())
"""

The problem is that until a child process is wait()ed on or its parent
process terminates (so that the child gets re-parented to init), the
child remains a zombie/defunct process. So if you have long-running
process spawning many subprocesses, you could end up having many
zombie processes, potentially filling up your process table at some
point. And this really sucks.
So I think it could be worth mentioning this somewhere in the
documentation (I mean, if we can find find such leaks inside CPython
code base, then it's definitely something that should be documented).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Tue May 10 18:17:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 May 2011 16:17:29 +0000
Subject: [issue12051] Segfault in JSONEncoder subclasses with
	check_circular=False
In-Reply-To: <1305044249.51.0.994959411456.issue12051@psf.upfronthosting.co.za>
Message-ID: <1305044249.51.0.994959411456.issue12051@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Subclasses of JSONEncoder that use check_circular=False can segfault json:
>>> import json
>>> class EndlessJSONEncoder(json.JSONEncoder):
...     def default(self, o):
...         return [o]
... 
>>> EndlessJSONEncoder(check_circular=False).encode(5j)
Segmentation fault

The attached patch fixes it raising a "RuntimeError: maximum recursion depth exceeded".

There might be other ways to get a segfault, because there are other recursive calls involving more functions (i.e. a calls b, and b calls a) that are not covered by the patch.

----------
assignee: ezio.melotti
components: Extension Modules
files: issue12051.diff
keywords: needs review, patch
messages: 135716
nosy: ezio.melotti
priority: normal
severity: normal
stage: commit review
status: open
title: Segfault in JSONEncoder subclasses with check_circular=False
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file21955/issue12051.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12051>
_______________________________________

From report at bugs.python.org  Tue May 10 18:27:48 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 16:27:48 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305044868.55.0.971127990426.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

That's interesting. You're saying that you've been using symlinked packages for some time and that it works for you. I filed this bug because it's never worked for me. Can you describe a little bit about the environment in which you've encountered this? Specifically, which Python version, how were the symlinks created, and what is the sys.path like?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 18:30:07 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 16:30:07 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305045007.46.0.66013401477.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

And since you seem to have some systems that honor symlinked packages, can you run the attached test_import_symlink_package.py and report the results?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 19:03:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 10 May 2011 17:03:48 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305047028.08.0.827300192182.issue6727@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Out of the patches listed, http://www.microsoft.com/technet/security/advisory/2269637.mspx is the only part that appears to be related in any way, although it doesn't specify a whole lot on the surface. The title is "Insecure Library Loading Could Allow Remote Code Execution", so I'm guessing they could have made some changes under the hood that could affect us.

Before we go down that road, running the script Jason suggested would be helpful in proving what works and doesn't work depending on what patches are installed and what version is running.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 19:05:45 2011
From: report at bugs.python.org (Waldemar Kornewald)
Date: Tue, 10 May 2011 17:05:45 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305047145.74.0.767368749731.issue6727@psf.upfronthosting.co.za>


Waldemar Kornewald <wkornewald at gmail.com> added the comment:

I'm using Python 2.6.6 on Windows 7 Professional with the latest service pack. My system is pretty bare bones. Do you have Visual Studio or the Visual Studio Redistributables?

Here's the output of your script (the last exception seems to be caused by the .pyc file, but apart from that it seems to work):


C:\Users\wkornewald\Downloads\a>test_import_symlink_package.py
Problem does not exist here.
Traceback (most recent call last):
  File "C:\Users\wkornewald\Downloads\a\test_import_symlink_package.py", line 66, in <module>
    os.rmdir(tagged)
WindowsError: [Error 145] The directory is not empty: 'sample-tagged'

C:\Users\wkornewald\Downloads\a>dir sample-tagged
 Volume in drive C has no label.
 Volume Serial Number is 50C8-BE90

 Directory of C:\Users\wkornewald\Downloads\a\sample-tagged

10.05.2011  19:04    <DIR>          .
10.05.2011  19:04    <DIR>          ..
10.05.2011  19:04               107 __init__.pyc
               1 File(s)            107 bytes
               2 Dir(s)  66.517.442.560 bytes free

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 19:20:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 17:20:51 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <E1QJqc4-0002Sl-SQ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 48743ad2d2ef by Antoine Pitrou in branch '2.7':
Issue #8498: In socket.accept(), allow to specify 0 as a backlog value in
http://hg.python.org/cpython/rev/48743ad2d2ef

New changeset 713006ecee0c by Antoine Pitrou in branch '3.2':
Issue #8498: In socket.accept(), allow to specify 0 as a backlog value in
http://hg.python.org/cpython/rev/713006ecee0c

New changeset 5e1ed84883c5 by Antoine Pitrou in branch 'default':
Issue #8498: In socket.accept(), allow to specify 0 as a backlog value in
http://hg.python.org/cpython/rev/5e1ed84883c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8498>
_______________________________________

From report at bugs.python.org  Tue May 10 19:22:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 May 2011 17:22:13 +0000
Subject: [issue8498] Cannot use backlog = 0 for sockets
In-Reply-To: <1271930573.09.0.998799390153.issue8498@psf.upfronthosting.co.za>
Message-ID: <1305048133.18.0.335851343479.issue8498@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thanks for the patch and review!

----------
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/issue8498>
_______________________________________

From report at bugs.python.org  Tue May 10 19:42:31 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 10 May 2011 17:42:31 +0000
Subject: [issue12050] unconsumed_tail of zlib.Decompress is not always cleared
	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <1305049351.95.0.601437602038.issue12050@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Thanks for the bug report. It seems that the code needs fixing. I'll look
into it this weekend.

----------
assignee:  -> nadeem.vawda
nosy: +nadeem.vawda
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12050>
_______________________________________

From report at bugs.python.org  Tue May 10 20:16:43 2011
From: report at bugs.python.org (Neil)
Date: Tue, 10 May 2011 18:16:43 +0000
Subject: [issue12052] round() erroneous for some large arguments
In-Reply-To: <1305051403.14.0.965488921979.issue12052@psf.upfronthosting.co.za>
Message-ID: <1305051403.14.0.965488921979.issue12052@psf.upfronthosting.co.za>


New submission from Neil <nasix at raytheon.com>:

round() returns incorrect results for certain large real-integer arguments. Demonstration via interpreter session:
>>> x = 2.0**52+1  # Huge, odd double integer near limits of what IEEE format can fully represent in its mantissa part
>>> round(x) - x   # Difference should be zero
1.0
>>> x = 2.0**53+1  # Even larger odd argument ...
>>> round(x) - x   # ... returns correct result!
0.0
>>> x = 2.0**51+1  # And a smaller argument ...
>>> round(x) - x   # ... also returns correct result!
0.0

Discussion:
It is not sufficient to implement round(x) as ceil(x - .5) for negative x and floor(x + .5) otherwise, since large integers near the representation limits will be changed incorrectly by these operations, apparently due to internal FPU semantics. One must test the argument first to see if it is a floating-point integer (e.g., math.floor(x) == x), and only bias & truncate towards zero if it is not. C math libraries that implement round(), such as on Linux & MacOS, do this correctly.

----------
components: None
messages: 135724
nosy: nasix
priority: normal
severity: normal
status: open
title: round() erroneous for some large arguments
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12052>
_______________________________________

From report at bugs.python.org  Tue May 10 20:20:06 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 May 2011 18:20:06 +0000
Subject: [issue12052] round() erroneous for some large arguments
In-Reply-To: <1305051403.14.0.965488921979.issue12052@psf.upfronthosting.co.za>
Message-ID: <1305051606.34.0.613373299417.issue12052@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Please upgrade:  this issue is already fixed in current versions of Python.

----------
nosy: +mark.dickinson
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12052>
_______________________________________

From report at bugs.python.org  Tue May 10 20:25:25 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 May 2011 18:25:25 +0000
Subject: [issue12052] round() erroneous for some large arguments
In-Reply-To: <1305051403.14.0.965488921979.issue12052@psf.upfronthosting.co.za>
Message-ID: <1305051925.34.0.332118268391.issue12052@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

(Duplicate of issue 7070.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12052>
_______________________________________

From report at bugs.python.org  Tue May 10 21:06:30 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 10 May 2011 19:06:30 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305054390.14.0.664085358478.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

Victor: AFAIK its not actually downcasting. The safe downcast just uses an assertion when debugging is enabled. I chose to use it because it seems to be a convention in the file.


Antoine: You say quirky, I say elegant :) Though I have no problem changing it. Also, I did think about leaving the fast-path the way it was. I thought what I have now might be more simple/readable. On second thought I will put that specific code in front of the lock.

I do feel, for some fundamental reason, that readinto() *should* always be faster than read(). I may look into the buffer argument overhead you mention.

Also, while we're at it, would it be worthwhile for me to make a patch for the prefech() method you proposed? Should a separate issue be created for that? I know there was no definitive answer in the email thread but it may be fun to experiment with as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue May 10 21:11:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 May 2011 19:11:09 +0000
Subject: [issue12051] Segfaults in _json while encoding objects
In-Reply-To: <1305044249.51.0.994959411456.issue12051@psf.upfronthosting.co.za>
Message-ID: <1305054669.51.0.355994521019.issue12051@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch fixes two more segfaults while encoding highly-nested objects.
Updated the issue title accordingly.

----------
title: Segfault in JSONEncoder subclasses with check_circular=False -> Segfaults in _json while encoding objects
Added file: http://bugs.python.org/file21956/issue12051-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12051>
_______________________________________

From report at bugs.python.org  Tue May 10 21:19:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 May 2011 19:19:02 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1305054390.14.0.664085358478.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305055129.3569.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Also, while we're at it, would it be worthwhile for me to make a patch
> for the prefech() method you proposed? Should a separate issue be
> created for that? I know there was no definitive answer in the email
> thread but it may be fun to experiment with as well.

It would be worthwhile and I am certainly in favour it it, although I
can't guarantee that it can go in in the end.
(yes, a separate issue should definitely be created)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue May 10 21:23:33 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Tue, 10 May 2011 19:23:33 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305055413.27.0.0887264297355.issue8824@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

I'm going to update the documentation to include the scope information. Should be done within a day.

----------
nosy: +jstadler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Tue May 10 21:37:25 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 10 May 2011 19:37:25 +0000
Subject: [issue12053] Add prefetch() for Buffered IO (experiment)
In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>
Message-ID: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>


New submission from John O'Connor <tehjcon at gmail.com>:

A prefetch() method for Buffered IO may greatly assist 3rd party buffering among other gains. If nothing else, it is worth experimenting with. 

Discussion on the topic is here: http://mail.python.org/pipermail/python-ideas/2010-September/008180.html

A summary of the method proposed (by Antoine Pitrou):

prefetch(self, buffer, skip, minread)

Skip `skip` bytes from the stream.  Then, try to read at
least `minread` bytes and write them into `buffer`. The file
pointer is advanced by at most `skip + minread`, or less if
the end of file was reached. The total number of bytes written
in `buffer` is returned, which can be more than `minread`
if additional bytes could be prefetched (but, of course,
cannot be more than `len(buffer)`).

Arguments:
- `buffer`: a writable buffer (e.g. bytearray)
- `skip`: number of bytes to skip (must be >= 0)
- `minread`: number of bytes to read (must be >= 0 and <= len(buffer))

----------
components: IO
messages: 135731
nosy: benjamin.peterson, haypo, jcon, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Add prefetch() for Buffered IO (experiment)
type: feature request
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12053>
_______________________________________

From report at bugs.python.org  Tue May 10 21:38:55 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 10 May 2011 19:38:55 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1305055129.3569.10.camel@localhost.localdomain>
Message-ID: <BANLkTinG0+jSp5Sdy1kwjjaYiKNGw4h5Sg@mail.gmail.com>


John O'Connor <tehjcon at gmail.com> added the comment:

No problem for me either way.

I created issue12053 to track that.

- John O'Connor

On Tue, May 10, 2011 at 3:19 PM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > Also, while we're at it, would it be worthwhile for me to make a patch
> > for the prefech() method you proposed? Should a separate issue be
> > created for that? I know there was no definitive answer in the email
> > thread but it may be fun to experiment with as well.
>
> It would be worthwhile and I am certainly in favour it it, although I
> can't guarantee that it can go in in the end.
> (yes, a separate issue should definitely be created)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9971>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file21957/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________
-------------- next part --------------
No problem for me either way.<div><br></div><div>I created issue12053 to track that.<br><div><br clear="all">- John O&#39;Connor <br>
<br><br><div class="gmail_quote">On Tue, May 10, 2011 at 3:19 PM, Antoine Pitrou <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>
Antoine Pitrou &lt;<a href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt; added the comment:<br>
<br>
</div><div class="im">&gt; Also, while we&#39;re at it, would it be worthwhile for me to make a patch<br>
&gt; for the prefech() method you proposed? Should a separate issue be<br>
&gt; created for that? I know there was no definitive answer in the email<br>
&gt; thread but it may be fun to experiment with as well.<br>
<br>
</div>It would be worthwhile and I am certainly in favour it it, although I<br>
can&#39;t guarantee that it can go in in the end.<br>
(yes, a separate issue should definitely be created)<br>
<div><div></div><div class="h5"><br>
----------<br>
<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/issue9971" target="_blank">http://bugs.python.org/issue9971</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div></div>

From report at bugs.python.org  Tue May 10 21:41:08 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 10 May 2011 19:41:08 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <1305056468.98.0.272545725799.issue12049@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Tue May 10 21:44:23 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 10 May 2011 19:44:23 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1305056663.81.0.682862138354.issue11888@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Why configure script check two times for log2 function ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Tue May 10 21:50:41 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 10 May 2011 19:50:41 +0000
Subject: [issue12053] Add prefetch() for Buffered IO (experiment)
In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>
Message-ID: <1305057041.19.0.290478779684.issue12053@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/issue12053>
_______________________________________

From report at bugs.python.org  Tue May 10 21:56:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 19:56:15 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <E1QJt2O-0007wU-WB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d3f9895e2e19 by Mark Dickinson in branch 'default':
Issue #11888: remove duplicate check for log2 in configure.in.
http://hg.python.org/cpython/rev/d3f9895e2e19

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Tue May 10 21:56:36 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 May 2011 19:56:36 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1305057396.62.0.593390719566.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Roumen.  Fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Tue May 10 22:03:26 2011
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Tue, 10 May 2011 20:03:26 +0000
Subject: [issue1350] IDLE - CallTips enhancement - show full doc-string in new
	window
In-Reply-To: <1193540394.75.0.209428889105.issue1350@psf.upfronthosting.co.za>
Message-ID: <1305057806.76.0.34319840645.issue1350@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Rejecting for now, out of date, doesn't apply, not single topic.

----------
resolution: out of date -> rejected
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1350>
_______________________________________

From report at bugs.python.org  Tue May 10 22:31:06 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 May 2011 20:31:06 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1305059466.47.0.959156420353.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Victor, what do you think about simply #undefining HAVE_LOG2 on Tiger (e.g. in pyport.h), so that the fallback log2 version is used there instead of the system version?

Does anyone know the appropriate preprocessor check for OS X <= 10.4?  I can get as far as "#ifdef __APPLE__", but don't know how to check for specific versions of OS X.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Tue May 10 22:33:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 10 May 2011 20:33:03 +0000
Subject: [issue12054] test_socket: replace custom _get_unused_port() by
	support.find_unused_port()
In-Reply-To: <1305059583.38.0.410171107289.issue12054@psf.upfronthosting.co.za>
Message-ID: <1305059583.38.0.410171107289.issue12054@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Lib/test/test_socket.py uses custom _get_unused_port to return a port which will be likely available for binding in some tests.
The same functionality is already provided by support.find_unuse_port, let's make use of it.
Patch attached.

----------
components: Tests
files: test_socket_unused_port.diff
keywords: patch
messages: 135738
nosy: neologix
priority: low
severity: normal
status: open
title: test_socket: replace custom _get_unused_port() by support.find_unused_port()
type: feature request
Added file: http://bugs.python.org/file21958/test_socket_unused_port.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12054>
_______________________________________

From report at bugs.python.org  Tue May 10 22:39:27 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 10 May 2011 20:39:27 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305059967.82.0.525455492223.issue9971@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


Removed file: http://bugs.python.org/file21957/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Tue May 10 23:38:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 21:38:26 +0000
Subject: [issue12054] test_socket: replace custom _get_unused_port() by
	support.find_unused_port()
In-Reply-To: <1305059583.38.0.410171107289.issue12054@psf.upfronthosting.co.za>
Message-ID: <E1QJud9-0007tR-8A@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 695a7acae392 by Antoine Pitrou in branch '3.2':
Issue #12054: use support.find_unused_port() instead of reinventing the wheel
http://hg.python.org/cpython/rev/695a7acae392

New changeset 1b9d6226a3dd by Antoine Pitrou in branch 'default':
Issue #12054: use support.find_unused_port() instead of reinventing the wheel
http://hg.python.org/cpython/rev/1b9d6226a3dd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12054>
_______________________________________

From report at bugs.python.org  Tue May 10 23:39:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 May 2011 21:39:32 +0000
Subject: [issue12054] test_socket: replace custom _get_unused_port() by
	support.find_unused_port()
In-Reply-To: <1305059583.38.0.410171107289.issue12054@psf.upfronthosting.co.za>
Message-ID: <1305063572.69.0.18403234645.issue12054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

An obvious one indeed, thank you :)

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12054>
_______________________________________

From report at bugs.python.org  Tue May 10 23:40:06 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 21:40:06 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305063606.23.0.231685283971.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks for that. The output is very telling.

First, it shows there's a bug in the test script where an exception occurs when it succeeds because a .pyc file is created and not properly cleaned up.

Second, it demonstrates that the bug as I reported it is not occurring in your environment.

This latter result tells me that I may be experiencing the same issue as you, but encountered it almost two years ago. This finding leads me to believe that the issue is less about the latest hotfix and more related to the VS redistributables. I almost certainly have some form of these redistributables installed as I usually have some form of Visual Studio installed.

The fact that it works in one environment and not another means I should be able to find the regression. I'll install a barebones Windows box and see how it behaves there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 23:42:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 21:42:46 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <E1QJuhY-0008FF-Lf@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 34871c3072c9 by Victor Stinner in branch 'default':
Issue #11888: skip some log2 tests on Mac OS X Tiger
http://hg.python.org/cpython/rev/34871c3072c9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Tue May 10 23:44:10 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 21:44:10 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305063850.64.0.0808427658815.issue6727@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file14741/test_import_symlink_package.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 23:44:55 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 21:44:55 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305063895.28.0.178887967881.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I updated the test script to avoid the error when the .pyc (or __pycache__) is created.

----------
Added file: http://bugs.python.org/file21959/test_import_symlink_package.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 10 23:55:12 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Tue, 10 May 2011 21:55:12 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305064512.85.0.310436423541.issue8824@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21960/exec_doc_touchup_2_x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Tue May 10 23:55:59 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Tue, 10 May 2011 21:55:59 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305064559.71.0.731115262728.issue8824@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


Added file: http://bugs.python.org/file21961/exec_doc_touchup_3_x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Wed May 11 00:00:40 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 22:00:40 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305064840.15.0.818381159204.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Confirmed the issue exists on Python 2.7 and 3.2

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Wed May 11 00:01:06 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 22:01:06 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305064866.36.0.647624143064.issue6727@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file21959/test_import_symlink_package.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Wed May 11 00:01:39 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 May 2011 22:01:39 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305064899.63.0.983417037163.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Updated script to run under Python 3.2 as well.

----------
Added file: http://bugs.python.org/file21962/test_import_symlink_package.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Wed May 11 00:02:43 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Tue, 10 May 2011 22:02:43 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305064963.8.0.591357176141.issue8824@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

Patches for 2.x and 3.x documentation related to 'exec'.

2.x
  Provides more information about scopes when using additional expressions
  for 'exec'. 2.x documentation for 'exec' is found in
  reference/simple_stmts.
3.x
  Provides more information about scopes when using additional expressions
  for 'exec'.  3.x documentation for 'exec' is found in library/functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Wed May 11 00:07:56 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Tue, 10 May 2011 22:07:56 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1305065276.41.0.396737637776.issue12014@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

Actually, that's the wrong place in MarkupIterator_next to include that loop. The attached diff has it in the right place. The results of "make test" here are:

328 tests OK.
1 test failed:
    test_unicode
25 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
    test_epoll test_gdb test_largefile test_msilib test_ossaudiodev
    test_readline test_smtpnet test_socketserver test_startfile
    test_timeout test_tk test_ttk_guionly test_urllib2net
    test_urllibnet test_winreg test_winsound test_xmlrpc_net
    test_zipfile64
1 skip unexpected on darwin:
    test_readline
make: [test] Error 1 (ignored)

test_unicode fails because it expects "{0[}".format() to raise an IndexError; instead, it raises a ValueError ("unmatched '{' in format") because it interprets the "}" as an *index*.

This can be avoided by changing the line 

                while (self->str.ptr < self->str.end && *self->str.ptr != ']') {

to 

                while (self->str.ptr < self->str.end-1 && *self->str.ptr != ']') {

In which case the test passes as is, or, obviously, by changing the expected exception in test_unicode.py.

----------
keywords: +patch
versions: +Python 2.6, Python 3.4
Added file: http://bugs.python.org/file21963/strformat.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Wed May 11 00:10:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 22:10:26 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1305065426.82.0.859013541028.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset 34871c3072c9 by Victor Stinner in branch 'default':
> Issue #11888: skip some log2 tests on Mac OS X Tiger

Oh... I realized that the test doesn't fail on Mac OS X Tiger PPC, only on Mac OS X Tiger x86. But I am too lazy to patch the test. Or should I do it?

I wait for the following build to close this issue.
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2507

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Wed May 11 00:15:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 22:15:39 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <E1QJvDO-0002HZ-9J@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6ad356525381 by Victor Stinner in branch 'default':
Close #10419, issue #6011: build_scripts command of distutils handles correctly
http://hg.python.org/cpython/rev/6ad356525381

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Wed May 11 00:23:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 22:23:16 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1305066196.52.0.509721899711.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New changeset 6ad356525381 by Victor Stinner in branch 'default':
Close #10419, issue #6011: build_scripts command of distutils handles correctly
http://hg.python.org/cpython/rev/6ad356525381

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Wed May 11 00:24:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 22:24:15 +0000
Subject: [issue12051] Segfaults in _json while encoding objects
In-Reply-To: <1305044249.51.0.994959411456.issue12051@psf.upfronthosting.co.za>
Message-ID: <E1QJvLW-0002rV-B8@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a21f5af476cb by Ezio Melotti in branch '2.7':
#12051: Fix segfault in json.dumps() while encoding highly-nested objects using the C accelerations.
http://hg.python.org/cpython/rev/a21f5af476cb

New changeset 9557e4eeb291 by Ezio Melotti in branch '3.1':
#12051: Fix segfault in json.dumps() while encoding highly-nested objects using the C accelerations.
http://hg.python.org/cpython/rev/9557e4eeb291

New changeset 3847b279d665 by Ezio Melotti in branch '3.2':
#12051: merge with 3.1.
http://hg.python.org/cpython/rev/3847b279d665

New changeset 821d7885c7ec by Ezio Melotti in branch 'default':
#12051: merge with 3.2.
http://hg.python.org/cpython/rev/821d7885c7ec

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12051>
_______________________________________

From report at bugs.python.org  Wed May 11 00:25:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 May 2011 22:25:49 +0000
Subject: [issue12051] Segfaults in _json while encoding objects
In-Reply-To: <1305044249.51.0.994959411456.issue12051@psf.upfronthosting.co.za>
Message-ID: <1305066349.64.0.410828499201.issue12051@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12051>
_______________________________________

From report at bugs.python.org  Wed May 11 00:32:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 22:32:16 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <E1QJvTS-0003X6-7B@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 47236a0cfb15 by Victor Stinner in branch '3.2':
Close #10419, issue #6011: build_scripts command of distutils handles correctly
http://hg.python.org/cpython/rev/47236a0cfb15

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Wed May 11 00:38:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 22:38:45 +0000
Subject: [issue11169] compileall doesn't support PEP 383 (undecodable
	paths/filenames)
In-Reply-To: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>
Message-ID: <E1QJvZj-00044b-OB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 85cfbbc7da60 by Victor Stinner in branch '3.2':
Issue #11169: compileall module uses repr() to format filenames and paths to
http://hg.python.org/cpython/rev/85cfbbc7da60

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11169>
_______________________________________

From report at bugs.python.org  Wed May 11 00:59:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2011 22:59:45 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <E1QJvu4-0005X9-22@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fd7d4639dae2 by Victor Stinner in branch '3.1':
Issue #10419: Fix build_scripts command of distutils to handle correctly
http://hg.python.org/cpython/rev/fd7d4639dae2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Wed May 11 01:04:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 23:04:44 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1305068684.08.0.750782613492.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I fixed #10419 in Python 3.2 and 3.3 (I applied my copy_script-2.patch fix). It is now possible to compile and install Python 3.2 and 3.3 with a non-ASCII prefix, so this issue can be done.

If you have issues when compiling Python with a non-ASCII prefix (and a locale encoding different than UTF-8), reopen the issue or open a more specific issue.

--

I don't want to backport fixes of this issue to Python 3.1, because Python 3.1 requires too much effort to handle correctly non-ASCII paths (not only for this specific issue). I consider that Python 3.1 is a stable release and should not be touched too much and non-ASCII path with a locale encoding different than UTF-8 is a corner case. If you have this issue with Python 3.1, please upgrade to Python 3.2 :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Wed May 11 01:06:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 May 2011 23:06:22 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1305068782.01.0.494898072891.issue10419@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue fixed in Python 3.1, 3.2, 3.3.

Thanks to Arfrever, I realized that this issue not only concerns the compilation of Python itself with a non-ASCII prefix (issue #6011), but the installation of any Python script containing a non-ASCII character. So I also fixed it in Python 3.1. I replaced os.fsencode(name) by name.encode(sys.getfilesystemencoding(), 'surrogateescape') in 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Wed May 11 02:26:27 2011
From: report at bugs.python.org (Adal Chiriliuc)
Date: Wed, 11 May 2011 00:26:27 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1305073587.13.0.268346812279.issue2857@psf.upfronthosting.co.za>


Adal Chiriliuc <adal.chiriliuc at gmail.com> added the comment:

I use the hachoir Python package to parse Java .class files and extract the strings from them and having support for Java modified UTF-8 would have been nice.

----------
nosy: +adalx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Wed May 11 04:38:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 May 2011 02:38:36 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305081516.37.0.49829211058.issue8824@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/issue8824>
_______________________________________

From report at bugs.python.org  Wed May 11 05:46:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 03:46:03 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <E1QK0N7-0007xH-Mz@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d59ec3aa442e by Senthil Kumaran in branch 'default':
Issue #12039 - Update the http.server.rst with the requirement to call `end_headers` after calling `send_header`.
http://hg.python.org/cpython/rev/d59ec3aa442e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Wed May 11 08:33:44 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 11 May 2011 06:33:44 +0000
Subject: [issue12046] Windows build identification incomplete
In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>
Message-ID: <1305095624.36.0.698343604213.issue12046@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ned: I agree this is desirable (i.e. the shipped binaries ought to carry proper build identification). I also think this is independent from this issue, though, since the changes to integrate build identification into the window build process won't be unrelated to any autoconf changes we may need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12046>
_______________________________________

From report at bugs.python.org  Wed May 11 08:42:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 11 May 2011 06:42:19 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1305096139.29.0.663497653883.issue12039@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Senthil: Almost, but not quite. end_headers() needs to be called even if send_header() isn't called (though it may be being called behind the scenes, that's not necessarily obvious to a user).

In my original unit-testing code, I had only

request.send_response(200)

and that caused a failure. My code now has to read

request.send_response(200)
request.end_headers()

No send_header() in sight! Perhaps the end_header() call requirement should also be mentioned in the docs on send_response().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Wed May 11 09:46:46 2011
From: report at bugs.python.org (Waldemar Kornewald)
Date: Wed, 11 May 2011 07:46:46 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305100006.04.0.337394617111.issue6727@psf.upfronthosting.co.za>


Waldemar Kornewald <wkornewald at gmail.com> added the comment:

I've tracked it down. It's caused by KB2467174 (http://support.microsoft.com/kb/2467174) and I can reliably reproduce it. Here's how to reproduce it:

Install *only* the "Microsoft Visual C++ 2008 Redistributable Package (x86)" from http://www.microsoft.com/downloads/en/confirmation.aspx?familyid=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en

Then, start Windows Update and click "Check for Updates" to get the new C++ 2008 Redistributable update and install that patch. Immediately symbolic links stop working. Then uninstall that patch and symlinks work again.

We're still trying to figure out what's causing this problem on my friend's computer. He doesn't have the 2008 Redistributable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Wed May 11 09:53:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 11 May 2011 07:53:09 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1305096139.29.0.663497653883.issue12039@psf.upfronthosting.co.za>
Message-ID: <20110511075259.GA5060@kevin>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Vinay, 

Normally, when one uses send_response() call, it is most often followed with
(multiple) send_header() calls and I updated the documentation keeping that in
mind.

Just calling of send_response() without any send_header and end_headers was an
interesting use-case and I started thinking if http.server's behavior should
change in order to support such a use-case.  But such a thing does not play
well with our recent change of caching and sending the headers.  For instance,
send_header and end_headers call might still be expected after send_response
and in which case, server's sending of headers would break. ( It would send it
two '\r\n' separated chunks, which is undesirable).

I think, it is best to add a note after send_response that it should be
followed by an end_header if the sever does not want to send any more headers.

I shall update this information.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Wed May 11 10:04:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 08:04:45 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <E1QK4PR-0000yR-J2@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4651bf40af8d by Senthil Kumaran in branch 'default':
issue12039 - update the documentation of send_response method in http.server.rst.
http://hg.python.org/cpython/rev/4651bf40af8d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Wed May 11 10:51:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 08:51:41 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1305054390.14.0.664085358478.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305103893.14362.4.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mardi 10 mai 2011 ? 19:06 +0000, John O'Connor a ?crit :
> Victor: AFAIK its not actually downcasting.

On Linux 32 bits, size_t is 32 bits, off_t is 64 bits. If the file size
is 4 GB, the downcast may truncate the size of 0 byte. It would be safer
to use off_t type for the n variable in buffered_readinto(), and maybe
cast to size_t on the call to memcpy. At memcpy, it is safe because the
maximum possible value of n is PY_SSIZE_T (2^31-1 on a 32 bits system),
which fit in a size_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Wed May 11 10:57:51 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 May 2011 08:57:51 +0000
Subject: [issue12044] subprocess.Popen.__exit__ doesn't wait for process end
In-Reply-To: <BANLkTinRDu0_r7fNPT4Aov=GpCVFybm-4A@mail.gmail.com>
Message-ID: <BANLkTimXGdZttwdqj9dvnG0Y2F_tzoVvkA@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

I didn't initially like the idea of __exit__ blocking on another
process... but the zombie issue is real does make me think we should
reconsider this and have it wait().

It is a backwards incompatible change if anyone has started using the
Popen context manager to launch a long running subprocess that they
did not want to wait for.  That should be exceedingly rare.

I say change the behavior to wait() in 3.3, 3.2.1 and 2.7.2.  Keep the
note in the documentation and turn it into something that stands out
better like a note or a warning suggesting that people always call
wait() after the Popen context manager exits if they need to be
compatible with 2.7.1 or earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Wed May 11 11:46:56 2011
From: report at bugs.python.org (Waldemar Kornewald)
Date: Wed, 11 May 2011 09:46:56 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305107216.0.0.923032019492.issue6727@psf.upfronthosting.co.za>


Waldemar Kornewald <wkornewald at gmail.com> added the comment:

That's really strange. We uninstalled Service Pack 1 from my friend's machine and now everything works. What I don't understand is why I don't have Service Pack 1 on my machine and why Windows Update also doesn't offer to install it. Does it have to be installed manually? :-/

Anyway, this means that the problem can be caused either by SP1 or by KB2467174.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Wed May 11 11:52:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 09:52:01 +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: <1305107521.32.0.0777227431537.issue12016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I asked if the change is correct on iconv mail list. Here is a copy of an answer.

De: 	Bruno Haible
?: 	[iconv mailing list]
Cc: 	Victor Stinner
Sujet: 	Re: [bug-gnu-libiconv] Invalid byte sequences and multiybyte encodings
Date: 	Tue, 10 May 2011 14:52:09 +0200

Hi,

> Someone opened an issue in Python bug tracker asking to change how
> invalid multibyte sequences are handled.
> http://bugs.python.org/issue12016

For UTF-8 the recommended way of handling malformed input is written down
in <http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt>. But the
principle applies to any encoding with a variable number of bytes per
character:
  When an invalid or malformed byte sequence is found, the smallest
  such byte sequence is transformed to U+FFFD (replacement character).

In particular, normally, if the first byte that is considered "wrong"
or "invalid" is a valid starter byte, the malformed byte sequence should
be considered to end before that byte. If it is not a valid starter
byte, then use your judgement.

For an example implementation, see
<http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/unistr/u8-mbtouc.c;hb=HEAD>
Here the return value is the number of bytes consumed. Look carefully
when it is 1, 2, 3, or 4.

> b'\xffabc'.decode('gb2312', 'replace') gives "?bc". The 'a' character is
> seen as part of a multibyte character of 2 bytes. Because {0xFF, 0x61}
> is invalid in GB2312, the two bytes are replaced by U+FFFD.
> 
> Is it the "right" way to to do?

It is better to replace only the 0xFF byte with U+FFFD, because 0x61 is a
valid first byte (even a complete character).

> UTF-8 decoder changed recently to ignore a single byte and restart the
> decoder, so '\xF1\x80\x41\x42\x43' is now decoded "?ABC" instead "?C".
> Should we do the same for all encodings?

Generally, yes.

> Or at least for asian encodings 
> (gb2312, gbk, gb18030, big5 family, ISO 2202 family, JIS family, EUC_KR,
> CP949, Big5, CP950, ...)?

For stateful encodings of the ISO 2202 family, you may want to ignore/replace
a complete escape sequence, where the syntax of escape sequences is defined
through general rules.

Bruno
-- 
In memoriam Siegfried R?del <http://en.wikipedia.org/wiki/Siegfried_R?del>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Wed May 11 12:05:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 May 2011 10:05:08 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1305103893.14362.4.camel@marge>
Message-ID: <1305108303.3642.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On Linux 32 bits, size_t is 32 bits, off_t is 64 bits. If the file size
> is 4 GB, the downcast may truncate the size of 0 byte.

We are not talking about the file size here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Wed May 11 12:54:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 10:54:00 +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: <1305111240.79.0.803012490256.issue12016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, the HZ codec has no test! And what is this horrible BLOB, Lib/test/cjkencodings_test.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Wed May 11 13:39:29 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Wed, 11 May 2011 11:39:29 +0000
Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile
In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>
Message-ID: <1305113969.29.0.629029473635.issue12018@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12018>
_______________________________________

From report at bugs.python.org  Wed May 11 13:39:34 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Wed, 11 May 2011 11:39:34 +0000
Subject: [issue12034] check_GetFinalPathNameByHandle() suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1305113974.41.0.25168195458.issue12034@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12034>
_______________________________________

From report at bugs.python.org  Wed May 11 13:39:41 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Wed, 11 May 2011 11:39:41 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1305113981.18.0.401149722644.issue11882@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Wed May 11 13:39:53 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Wed, 11 May 2011 11:39:53 +0000
Subject: [issue12045] external shell command executed twice in
	ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <1305113993.69.0.517648594537.issue12045@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy: +sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Wed May 11 13:56:41 2011
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 11 May 2011 11:56:41 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>
Message-ID: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

The attached file demonstrates

----------
components: Library (Lib)
files: bug.py
messages: 135770
nosy: dabrahams
priority: normal
severity: normal
status: open
title: doctest not working on nested functions
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21964/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Wed May 11 14:24:06 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 11 May 2011 12:24:06 +0000
Subject: [issue12039] test_logging: bad file descriptor on FreeBSD bot
In-Reply-To: <1304964046.46.0.0936744885489.issue12039@psf.upfronthosting.co.za>
Message-ID: <1305116646.74.0.37371334684.issue12039@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12039>
_______________________________________

From report at bugs.python.org  Wed May 11 14:29:23 2011
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 11 May 2011 12:29:23 +0000
Subject: =?utf-8?b?W2lzc3VlMTIwNTZdICLigKYiIChIT1JJWk9OVEFMIEVMTElQU0lTKSBzaG91?=
	=?utf-8?q?ld_be_an_alternative_syntax_for_=22=2E=2E=2E=22_=28FULL_STOP_FU?=
	=?utf-8?q?LL_STOP_FULL_STOP=29?=
In-Reply-To: <1305116963.2.0.886557706655.issue12056@psf.upfronthosting.co.za>
Message-ID: <1305116963.2.0.886557706655.issue12056@psf.upfronthosting.co.za>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

In Python 3, "..." became useable as a normal expression, and translates into an ellipsis instance.

Unicode defines an ellipsis character "?" (U+2026 HORIZONTAL ELLIPSIS) which is canonically equivalent to a 3-sequence of FULL STOP [U+002E U+002E U+002E]

I think it would be nice if Python supported "?" as an alternative to "..."

----------
components: Interpreter Core, Unicode
messages: 135771
nosy: xmorel
priority: normal
severity: normal
status: open
title: "?" (HORIZONTAL ELLIPSIS) should be an alternative syntax for "..." (FULL STOP FULL STOP FULL STOP)
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12056>
_______________________________________

From report at bugs.python.org  Wed May 11 14:52:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 May 2011 12:52:43 +0000
Subject: =?utf-8?b?W2lzc3VlMTIwNTZdICLigKYiIChIT1JJWk9OVEFMIEVMTElQU0lTKSBzaG91?=
	=?utf-8?q?ld_be_an_alternative_syntax_for_=22=2E=2E=2E=22_=28FULL_STOP_FU?=
	=?utf-8?q?LL_STOP_FULL_STOP=29?=
In-Reply-To: <1305116963.2.0.886557706655.issue12056@psf.upfronthosting.co.za>
Message-ID: <1305118363.69.0.459628965552.issue12056@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12056>
_______________________________________

From report at bugs.python.org  Wed May 11 14:55:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 12:55:51 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1305118551.23.0.106349254941.issue2857@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

utf_8_java.patch: Implement "utf-8-java" encoding.
 * It has no alias
 * 'a\0b'.encode('utf-8-java') returns b'a\xc0\x80b'
 * b'a\xc0\x80b'.decode('utf-8-java') returns 'a\x00b'
 * I added some tests to utf-8 codec (test_invalid, test_null_byte)
 * I added many tests for utf-8-java codec
 * I choosed to copy utf8_code_length as utf8java_code_length instead of adding some if to not slow down UTF-8 codec
 * Decoder: 2 byte sequences may be *a little bit* slower for UTF-8:
"if ((s[1] & 0xc0) != 0x80)"
   is replaced by 
"if ((ch <= 0x007F && (ch != 0x0000 || !java)) || ch > 0x07FF)"
 * Encoder: encode chars in U+0000-U+007F may be *a little bit* slower for UTF-8: I added (ch == 0x00 && java) test

For the doc, I just added a line "utf-8-java" in the codec list, but I did not add a paragraph to explain how this codec is different to utf-8. Does anyone have a suggestion?

----------
keywords: +patch
Added file: http://bugs.python.org/file21965/utf_8_java.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Wed May 11 15:01:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:01:58 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

All CJK codecs have tests except the chinese HZ codec, I don't know why.

But to add a test, I need to add data to Lib/test/cjkencodings_test.py and the format of this file is not documented. It is not too difficult to understand the format by reading the code of the tests, but it's hard to maintain these tests (add more tests or change a test).

I need tests to be able to patch the codec to fix #12016.

My plan is to:

 - Change Lib/test/cjkencodings_test.py format: use two files for each encoding (one in the tested encoding, one in UTF-8)
 - Add tests to the HZ codec
 - Close this issue
 - Fix #12016

----------
components: Library (Lib), Unicode
messages: 135773
nosy: cdqzzy, ezio.melotti, haypo, lemburg, terry.reedy
priority: normal
severity: normal
status: open
title: HZ codec has no test
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:18:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 13:18:19 +0000
Subject: [issue11799] urllib HTTP authentication behavior with unrecognized
	auth method
In-Reply-To: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>
Message-ID: <E1QK9Iq-0002OK-QB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6072db001b51 by Senthil Kumaran in branch 'default':
Fix closes Issue #11799: urllib.request Authentication Handlers will raise a
http://hg.python.org/cpython/rev/6072db001b51

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11799>
_______________________________________

From report at bugs.python.org  Wed May 11 15:18:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:18:38 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305119918.09.0.446860781638.issue12057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file21966/convert_cjkencodings.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:18:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:18:58 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305119938.98.0.430447451883.issue12057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file21967/cjkencodings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:20:59 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 11 May 2011 13:20:59 +0000
Subject: [issue11799] urllib HTTP authentication behavior with unrecognized
	auth method
In-Reply-To: <1302204770.2.0.571328195993.issue11799@psf.upfronthosting.co.za>
Message-ID: <1305120059.79.0.894055758574.issue11799@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11799>
_______________________________________

From report at bugs.python.org  Wed May 11 15:27:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:27:17 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305120437.06.0.711514473246.issue12057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21967/cjkencodings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:27:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:27:31 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305120451.57.0.234137399726.issue12057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file21968/cjkencodings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:27:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:27:42 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305120462.44.0.681699452679.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

convert_cjkencodings.py is script to replace Lib/test/cjkencodings_test.py by a Lib/test/cjkencodings/ directory:
---
big5hkscs.txt
big5hkscs-utf8.txt
big5.txt
big5-utf8.txt
cp949.txt
cp949-utf8.txt
euc_jisx0213.txt
euc_jisx0213-utf8.txt
euc_jp.txt
euc_jp-utf8.txt
euc_kr.txt
euc_kr-utf8.txt
gb18030.txt
gb18030-utf8.txt
gb2312.txt
gb2312-utf8.txt
gbk.txt
gbk-utf8.txt
johab.txt
johab-utf8.txt
shift_jis.txt
shift_jis-utf8.txt
shift_jisx0213.txt
shift_jisx0213-utf8.txt
---

cjkencodings.patch fixes Lib/test/test_multibytecodec_support.py to use the directoy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:32:00 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 11 May 2011 13:32:00 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1305118551.23.0.106349254941.issue2857@psf.upfronthosting.co.za>
Message-ID: <4DCA8FC6.7050902@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thanks for the patch, Victor.

Some comments on the patch:

 * the codec will have to be able to work with lone surrogates
   (see the wikipedia page explaining this detail), which the
   UTF-8 codec in Python 3.x no longer does, so another special
   case is due for this difference

 * we should not make the standard UTF-8 codec slower just to
   support a variant of UTF-8 which will only get marginal use;
   for the decoder, the changes are minimal, so that's fine,
   but for the decoder you are changing the most often used
   code branch to check for NUL bytes - we need a better solution
   for this, even if it means having to use a separte encode_utf8java
   function

Since the ticket was opened in 2008, the common name of the
codec appears to have changed from "UTF-8 Java" to "Modified UTF-8"
or "MUTF-8" as short alias:

 * http://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8
    (change in http://en.wikipedia.org/w/index.php?title=UTF-8&diff=next&oldid=291829304)
 * http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
    (scroll down to "Modified UTF-8")
 * http://developer.android.com/reference/java/io/DataInput.html
    (this is for Android)

So I guess we should adapt to the name to the now common name
and call it "ModifiedUTF8" in the C API and add these aliases:
"utf-8-modified", "mutf-8" and "modified-utf-8".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Wed May 11 15:32:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:32:34 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305120754.36.0.109356229389.issue12057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +HZ codec has no test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:32:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:32:46 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305120766.9.0.431977828631.issue12057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies:  -HZ codec has no test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:32:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:32:55 +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: <1305120775.54.0.985169223836.issue12016@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
dependencies: +HZ codec has no test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Wed May 11 15:38:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 13:38:05 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305121085.48.0.971557765995.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New files should be marked as binary in Mercurial: add "Lib/test/cjkencodings/* = BIN" in .hgeol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 15:44:47 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Wed, 11 May 2011 13:44:47 +0000
Subject: =?utf-8?b?W2lzc3VlMTIwNTZdICLigKYiIChIT1JJWk9OVEFMIEVMTElQU0lTKSBzaG91?=
	=?utf-8?q?ld_be_an_alternative_syntax_for_=22=2E=2E=2E=22_=28FULL_STOP_FU?=
	=?utf-8?q?LL_STOP_FULL_STOP=29?=
In-Reply-To: <1305116963.2.0.886557706655.issue12056@psf.upfronthosting.co.za>
Message-ID: <1305121487.48.0.305900026119.issue12056@psf.upfronthosting.co.za>


Brandon Craig Rhodes <brandon at rhodesmill.org> added the comment:

But if we allow for ellipsis, then would we not also have to start allowing characters like ? and ? in Python? And the problem with any of these (admittedly very attractive) substitutions is that they seem to abandon the principle of there being One Obvious Way of typing any given expression. Instead there would now be several alternate ways, with different styles in different codebases and, I think, something of a visual and symbolic mess resulting. I like each symbol to have exactly one possible representation.

----------
nosy: +brandon-rhodes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12056>
_______________________________________

From report at bugs.python.org  Wed May 11 15:46:19 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 11 May 2011 13:46:19 +0000
Subject: =?utf-8?b?W2lzc3VlMTIwNTZdICLigKYiIChIT1JJWk9OVEFMIEVMTElQU0lTKSBzaG91?=
	=?utf-8?q?ld_be_an_alternative_syntax_for_=22=2E=2E=2E=22_=28FULL_STOP_FU?=
	=?utf-8?q?LL_STOP_FULL_STOP=29?=
In-Reply-To: <1305116963.2.0.886557706655.issue12056@psf.upfronthosting.co.za>
Message-ID: <1305121579.69.0.449289885363.issue12056@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Making such substitutions is a good way to introduce subtle bugs.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12056>
_______________________________________

From report at bugs.python.org  Wed May 11 16:27:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 14:27:43 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <E1QKAO2-0000e3-R8@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e7c62e0981c7 by Senthil Kumaran in branch 'default':
Fix closed Issue #11968 - the start_response header values in wsgiref shoudl be
http://hg.python.org/cpython/rev/e7c62e0981c7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11968>
_______________________________________

From report at bugs.python.org  Wed May 11 16:29:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 11 May 2011 14:29:20 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <1305124160.95.0.93033880894.issue11968@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11968>
_______________________________________

From report at bugs.python.org  Wed May 11 16:38:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 14:38:05 +0000
Subject: [issue11968] wsgiref's wsgi application sample code does not work
In-Reply-To: <1304229384.21.0.895279111303.issue11968@psf.upfronthosting.co.za>
Message-ID: <E1QKAY7-0001cT-Ji@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5add0c01933f by Senthil Kumaran in branch '3.2':
Issue #11968 - the start_response header values in wsgiref shoudl be str not
http://hg.python.org/cpython/rev/5add0c01933f

New changeset 482f60d6a687 by Senthil Kumaran in branch 'default':
[Merge Branch] Issue #11968 - the start_response header values in wsgiref shoudl be
http://hg.python.org/cpython/rev/482f60d6a687

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11968>
_______________________________________

From report at bugs.python.org  Wed May 11 16:54:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 May 2011 14:54:50 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1305125690.98.0.315302942062.issue12014@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
stage:  -> patch review
versions:  -Python 2.6, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Wed May 11 17:13:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 May 2011 15:13:37 +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: <1305126817.29.0.230647556924.issue12013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is the original bug still present in your new install?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Wed May 11 18:44:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 11 May 2011 16:44:37 +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: <1305132277.12.0.236098636658.issue12044@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm re-opening this issue, since Gregory agrees to change the current behaviour.
Patch attached (along with test and documentation update).

----------
components: +Library (Lib)
keywords: +patch
resolution: rejected -> 
status: closed -> open
Added file: http://bugs.python.org/file21969/subprocess_zombie.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Wed May 11 18:51:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 May 2011 16:51:41 +0000
Subject: [issue12058] Minor edits to comments in faulthandler
In-Reply-To: <1305132700.94.0.64826444937.issue12058@psf.upfronthosting.co.za>
Message-ID: <1305132700.94.0.64826444937.issue12058@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I fixed or improved some comments in faulthandler.  The only non-trivial change is a replacement of ?until? to ?before? (until did not make sense).  Please review and if you agree, commit.

----------
files: faulthandler-comments.diff
keywords: patch
messages: 135784
nosy: eric.araujo, haypo
priority: normal
severity: normal
status: open
title: Minor edits to comments in faulthandler
versions: Python 3.3
Added file: http://bugs.python.org/file21970/faulthandler-comments.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12058>
_______________________________________

From report at bugs.python.org  Wed May 11 19:05:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 May 2011 17:05:30 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305133530.72.0.884287770563.issue12057@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Looking at cjkencodings.py the format is pretty clear. The file consists of one statement that creates one dict that maps encoding names to a pair of (encoded) byte strings. The bytes literals are entirely hex escapes, with a maximum of 16 per chunk (line). From the usage you deduced that the first is encoded with named encoding and the second encoded with utf-8. (For anyone wondering, a separate utf-8 strings is needed for each encoding because each other encoding is limited to a different subset of unicode chars.)

So I am not completely convinced that pulling the file apart is a complete win. Another entry could be added (the file is formatted with that possibility in mind), but it would certainly be much easier if the original formatting program were available. I do have a couple of questions.

1. Did one of us create the test strings (if so, how) or do they come from an authoritative source (like the unicode site) that created and checked them with their reference implementations. If so, the missing pair *is* a puzzle. Anyway, if so, is there any possibility that we would need to get new test strings from that source? Or are the limitations of these coding definitely fixed.

2. If you create a test file for hz codec with the hz codec, how do we know it is correct? It would only serve to detect changes in the future.

----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 19:10:27 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 11 May 2011 17:10:27 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1305133827.39.0.199485980596.issue10419@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I have committed the fix for Distribute:
https://bitbucket.org/tarek/distribute/changeset/97f12f8f6bf1

(However Distribute would fail to create entry points scripts if sys.executable contained unencodable characters.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Wed May 11 19:27:44 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 11 May 2011 17:27:44 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305133530.72.0.884287770563.issue12057@psf.upfronthosting.co.za>
Message-ID: <4DCAC705.4030803@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Terry J. Reedy wrote:
> 
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> Looking at cjkencodings.py the format is pretty clear. The file consists of one statement that creates one dict that maps encoding names to a pair of (encoded) byte strings. The bytes literals are entirely hex escapes, with a maximum of 16 per chunk (line). From the usage you deduced that the first is encoded with named encoding and the second encoded with utf-8. (For anyone wondering, a separate utf-8 strings is needed for each encoding because each other encoding is limited to a different subset of unicode chars.)
> 
> So I am not completely convinced that pulling the file apart is a complete win. Another entry could be added (the file is formatted with that possibility in mind), but it would certainly be much easier if the original formatting program were available. I do have a couple of questions.
> 
> 1. Did one of us create the test strings (if so, how) or do they come from an authoritative source (like the unicode site) that created and checked them with their reference implementations. If so, the missing pair *is* a puzzle. Anyway, if so, is there any possibility that we would need to get new test strings from that source? Or are the limitations of these coding definitely fixed.
> 
> 2. If you create a test file for hz codec with the hz codec, how do we know it is correct? It would only serve to detect changes in the future.

Victor, could you please contact Hye-Shik Chang <perky at FreeBSD.org>
before making significant changes to the test suite.

Wouldn't it be better to just use example strings from the RFC and
keep the design as it is ?

http://tools.ietf.org/html/rfc1843

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 20:19:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 18:19:58 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <E1QKE0c-0004YJ-Gn@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 82cfbe2ddfbb by Kurt B. Kaiser in branch '3.1':
Issue #1028: Tk returns invalid Unicode null in %A: UnicodeDecodeError.
http://hg.python.org/cpython/rev/82cfbe2ddfbb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed May 11 20:38:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 18:38:09 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305133530.72.0.884287770563.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305139071.12577.14.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Looking at cjkencodings.py the format is pretty clear. The file
> consists of one statement that creates one dict that maps encoding
> names to a pair of (encoded) byte strings. The bytes literals are
> entirely hex escapes, with a maximum of 16 per chunk (line). From the
> usage you deduced that the first is encoded with named encoding and
> the second encoded with utf-8. (For anyone wondering, a separate utf-8
> strings is needed for each encoding because each other encoding is
> limited to a different subset of unicode chars.)
> 
> So I am not completely convinced that pulling the file apart is a
> complete win. Another entry could be added (the file is formatted with
> that possibility in mind), but it would certainly be much easier if
> the original formatting program were available.

With classic plain text files you don't need tools to convert a test
case. Use your text editor and you can use command line tools like
iconv, to modify an existing testcase or add a new testcase.

Example:

$ iconv -f utf-8 Lib/test/cjkencodings/gb18030-utf8.txt -t gb18030 -o
Lib/test/cjkencodings/gb18030-2.txt
$ md5sum Lib/test/cjkencodings/gb18030-2.txt
Lib/test/cjkencodings/gb18030.txt 
f8469bf751a9239a1038217e69d82532  Lib/test/cjkencodings/gb18030-2.txt
f8469bf751a9239a1038217e69d82532  Lib/test/cjkencodings/gb18030.txt

(Cool, iconv gives the same result :-))

> 1. Did one of us create the test strings (if so, how) or do they come
> from an authoritative source (like the unicode site) that created and
> checked them with their reference implementations.

Each encoding uses a different text, I don't know why. It's difficult to
see this fact by reading hexadecimal codes...

> Anyway, if so, is there any possibility that we would need to get new
> test strings from that source? Or are the limitations of these coding
> definitely fixed.

I don't understand why different texts are used. Why not just using the
same original text for all testcases? One reason can be that some
encodings (e.g. ISO 2202) use escape sequences to change the current
encoding. Or maybe because the characters are different (chinese vs
japanese characters?).

Anyway, we can use multiple testcases for each encoding.

> 2. If you create a test file for hz codec with the hz codec, how do we
> know it is correct? It would only serve to detect changes in the
> future.

We can use another codec than Python codec. The iconv command line
program doesn't know the "HZ" encoding (but it knows a lot of other
encodings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 20:38:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 18:38:56 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <4DCAC705.4030803@egenix.com>
Message-ID: <1305139115.12577.15.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 11 mai 2011 ? 17:27 +0000, Marc-Andre Lemburg a ?crit :
> Victor, could you please contact Hye-Shik Chang <perky at FreeBSD.org>
> before making significant changes to the test suite.

Good idea, done.

> Wouldn't it be better to just use example strings from the RFC and
> keep the design as it is ?
> 
> http://tools.ietf.org/html/rfc1843

Nice, this RFC contains some useful examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 20:40:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 11 May 2011 18:40:08 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <20110502190933.GA42748@sherwood.local>
Message-ID: <20110511183946.GA8103@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

For the record:
On Mac OS X 10.6.7, ,HFS, case sensitive` updates st_atime by
itself *once only*.  It does so ~0.75 seconds after os.utime() (+)
was called.  A time.sleep(0.8) can be used to detect this automatic
update reliably (about 50 tests with changing load all succeeded).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11935>
_______________________________________

From report at bugs.python.org  Wed May 11 20:43:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 18:43:57 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305139437.37.0.812402921452.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Lib/test/cjkencodings_test.py was created when CJK were introduced in Python: changeset 31386 by Hye-Shik Chang <hyeshik at gmail.com>.

"Add CJK codecs support as discussed on python-dev. (SF #873597)

Several style fixes are suggested by Martin v. Loewis and
Marc-Andre Lemburg. Thanks!"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 20:58:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 18:58:16 +0000
Subject: [issue12058] Minor edits to comments in faulthandler
In-Reply-To: <1305132700.94.0.64826444937.issue12058@psf.upfronthosting.co.za>
Message-ID: <E1QKEbh-0008Dv-BY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5f407b5479f5 by Victor Stinner in branch 'default':
Issue #12058: Minor edits to comments in faulthandler
http://hg.python.org/cpython/rev/5f407b5479f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12058>
_______________________________________

From report at bugs.python.org  Wed May 11 20:59:19 2011
From: report at bugs.python.org (Ian Wienand)
Date: Wed, 11 May 2011 18:59:19 +0000
Subject: [issue12059] hashlib does not handle missing hash functions correctly
In-Reply-To: <1305140359.29.0.351905173932.issue12059@psf.upfronthosting.co.za>
Message-ID: <1305140359.29.0.351905173932.issue12059@psf.upfronthosting.co.za>


New submission from Ian Wienand <ian at wienand.org>:

If one of the hash functions isn't defined in _hashlib, the code suggests it should just be skipped

===
      # this one has no builtin implementation, don't define it
                pass
===

This doesn't happen however; due to ImportError not being caught the module decides the whole _hashlib module isn't available and tries to fall back to the older individual libraries.  You then get thrown an unrelated error about _md5 being unavailable

You can easily replicate this

---
$ python
Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
...     raise ValueError
... 
>>> import _hashlib
>>> _hashlib.openssl_sha224 = foo
>>> import hashlib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/hashlib.py", line 136, in <module>
    md5 = __get_builtin_constructor('md5')
  File "/usr/lib/python2.6/hashlib.py", line 63, in __get_builtin_constructor
    import _md5
ImportError: No module named _md5
>>> 
---

I think the solution is to catch the ImportError in __get_builtin_constructor and, if caught, consider the hash function unsupported

----------
files: hashlib.py.diff
keywords: patch
messages: 135794
nosy: Ian.Wienand
priority: normal
severity: normal
status: open
title: hashlib does not handle missing hash functions correctly
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file21971/hashlib.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12059>
_______________________________________

From report at bugs.python.org  Wed May 11 21:00:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 19:00:33 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1305140433.19.0.041983349865.issue1028@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm working on #2857 which adds the "Modified UTF-8" ("utf-8-java"?) codec to Python. We can maybe use it instead of raising an error in 3.3?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed May 11 21:00:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 19:00:36 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1305140436.32.0.306459907289.issue2857@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #1028.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Wed May 11 21:02:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 19:02:24 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305140544.62.0.0718595012994.issue12057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +hyeshik.chang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 21:02:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 19:02:32 +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: <1305140552.12.0.506823823633.issue12016@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +hyeshik.chang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Wed May 11 21:27:20 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 11 May 2011 19:27:20 +0000
Subject: [issue12050] unconsumed_tail of zlib.Decompress is not always cleared
	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <1305142040.78.0.445963664814.issue12050@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/issue12050>
_______________________________________

From report at bugs.python.org  Wed May 11 21:48:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 19:48:54 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1305143334.78.0.904172704404.issue2857@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Benchmark:
a) ./python -m timeit "(b'\xc3\xa9' * 10000).decode('utf-8')"
b)./python -m timeit "(''.join( map(chr, range(0, 128)) )*1000).encode('utf-8')"
c) ./python -m timeit "f=open('Misc/ACKS', encoding='utf-8'); acks=f.read(); f.close()" "acks.encode('utf-8')"
d) ./python -m timeit "f=open('Misc/ACKS', 'rb'); acks=f.read(); f.close()" "acks.decode('utf-8')"

Original -> patched (smallest value of 3 runs):
a) 85.8 usec -> 83.4 usec (-2.8%)
b) 548 usec -> 688 usec  (+25.5%)
c) 132 usec -> 144 usec (+9%)
d) 65.9 usec -> 67.3 usec (+2.1%)

Oh, decode 2 bytes sequences are faster with my patch. Strange :-)

But 25% slower to encode a pure ASCII text is not a good news.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2857>
_______________________________________

From report at bugs.python.org  Wed May 11 21:59:22 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 11 May 2011 19:59:22 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305143962.98.0.852349685142.issue11948@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I first would like to apologize if my comments were interpreted like I'd like to do a poor quality job, that's actually the opposite! I just get caught by surprise how a simple change in a word to better join two paragraphs grows up like this - but that's perfectly fine and understandable we want to be as detailed and precise as possible

Here's the fifth version of the patch, including Terry's suggestions - thanks!

----------
Added file: http://bugs.python.org/file21972/issue11948-v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Wed May 11 22:01:45 2011
From: report at bugs.python.org (Alex Lai)
Date: Wed, 11 May 2011 20:01:45 +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: <1305144105.39.0.172167824686.issue12013@psf.upfronthosting.co.za>


Alex Lai <alex_lai at scotiacapital.com> added the comment:

I haven't get time to upgarde my workstation yet. I don't know when I'm going to do it. I compile the software successfully on the other server. and that's enough for me.

Thanks,
Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Wed May 11 22:09:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 20:09:22 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1305144562.62.0.179489774268.issue11888@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I wait for the following build to close this issue.
> http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2507

Oh, it's the wrong build. The correct build is:
http://www.python.org/dev/buildbot/all/builders/x86%20Tiger%203.x/builds/2508

And it passed so I close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Wed May 11 22:12:57 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 May 2011 20:12:57 +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: <1305144777.72.0.79610805301.issue12044@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Wed May 11 22:25:36 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 May 2011 20:25:36 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305145536.69.0.482267952747.issue12057@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Reading http://tools.ietf.org/html/rfc1843 suggests that the reason that there is no HZ pair in cjkencodings.py is that it is not a cjkencoding. Instead it is a formatter or meta-encoding for intermixing ascii codes and GB2312(-80) codes. (I assume the '-80' suffix means the 1980 version.)

In a bytes environment, I believe a strict HZ decoder would simply separate the input bytes into alternating ascii and GB bytes by splitting on the shift chars, changing '~~' to '~', and deleting '~\n' (2 chars). So it would need a special-case test. Python shifts between ascii and GB2312 decoders to produce a unicode stream. Because of the deletion of line-continuation markers, the codec is not 1 to 1. A test sentence should contain both that and an encoded ~.

>>> hz=b'''\
This ASCII sentence has a tilde: ~~.
The next sentence is in GB.~{<:Ky2;S{#,~}~
~{NpJ)l6HK!#~}Bye.'''
>>> hz
b'This ASCII sentence has a tilde: ~~.\nThe next sentence is in GB.~{<:Ky2;S{#,~}~\n~{NpJ)l6HK!#~}Bye.'
>>> HZ = hz.decode('HZ')
>>> HZ
'This ASCII sentence has a tilde: ~.\nThe next sentence is in GB.??????????Bye.'
# second '\n' deleted
>>> HZ.encode('HZ')
b'This ASCII sentence has a tilde: ~.\nThe next sentence is in GB.~{<:Ky2;S{#,NpJ)l6HK!#~}Bye.'
# no '~}~\n~{' in the middle of GC codes.

I believe hz and u8=HZ.encode() should work as a test pair for the working of the hz parser itself:
>>> u8 = HZ.encode()
>>> u8
b'This ASCII sentence has a tilde: ~.\nThe next sentence is in GB.\xe5\xb7\xb1\xe6\x89\x80\xe4\xb8\x8d\xe6\xac\xb2\xef\xbc\x8c\xe5\x8b\xbf\xe6\x96\xbd\xe6\x96\xbc\xe4\xba\xba\xe3\x80\x82Bye.'
>>> u8.decode() == hz.decode('HZ')
True

However, I have no idea what the hz codec is doing with the shifted byte pairs between '~{' and '~}' All the gb codecs decode b'<:Ky2;S{#,NpJ)l6HK!#' to '<:Ky2;S{#,NpJ)l6HK!#' (ie, ascii chars to same unicode chars). And they encode '??????????' to bytes with the high bit set.

I figured it out. The 1995 rfc says "A GB (GB1 and GB2) code is a two byte code, where the first byte is in the range $21-$77   (hexadecimal), and the second byte is in the range $21-$7E." This was in the days of for 7-bit bytes, at least for safe transmission. Now that we use 8-bit bytes nearly everywhere, the gb specs have probably be updated since 1980. This makes hz rather obsolete, since high-bit unset ascii codes and high-bit set gb codes can be mixed without the hz wrapping. In any case, Python's gb codecs act this way. So the hz codec is setting and unsetting the high bit when passing bytes to and from gb codec (assuming it does not use a modified version internally).
>>> hhz = [c - 128 for c in '??????????'.encode('GB2312')]
>>> bytes(hhz)
b'<:Ky2;S{#,NpJ)l6HK!#'

Perhaps there should be a separate test like the above to be sure that hz really uses GB2312-80, as specified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 22:27:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 May 2011 20:27:31 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305145651.2.0.426186452371.issue12057@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Reading http://tools.ietf.org/html/rfc1843 suggests that the reason that there is no HZ pair in cjkencodings.py is that it is not a cjkencoding. Instead it is a formatter or meta-encoding for intermixing ascii codes and GB2312(-80) codes. (I assume the '-80' suffix means the 1980 version.)

In a bytes environment, I believe a strict HZ decoder would simply separate the input bytes into alternating ascii and GB bytes by splitting on the shift chars, changing '~~' to '~', and deleting '~\n' (2 chars). So it would need a special-case test. Python shifts between ascii and GB2312 decoders to produce a unicode stream. Because of the deletion of line-continuation markers, the codec is not 1 to 1. A test sentence should contain both that and an encoded ~.

>>> hz=b'''\
This ASCII sentence has a tilde: ~~.
The next sentence is in GB.~{<:Ky2;S{#,~}~
~{NpJ)l6HK!#~}Bye.'''
>>> hz
b'This ASCII sentence has a tilde: ~~.\nThe next sentence is in GB.~{<:Ky2;S{#,~}~\n~{NpJ)l6HK!#~}Bye.'
>>> HZ = hz.decode('HZ')
>>> HZ
'This ASCII sentence has a tilde: ~.\nThe next sentence is in GB.??????????Bye.'
# second '\n' deleted
>>> HZ.encode('HZ')
b'This ASCII sentence has a tilde: ~.\nThe next sentence is in GB.~{<:Ky2;S{#,NpJ)l6HK!#~}Bye.'
# no '~}~\n~{' in the middle of GC codes.

I believe hz and u8=HZ.encode() should work as a test pair for the working of the hz parser itself:
>>> u8 = HZ.encode()
>>> u8
b'This ASCII sentence has a tilde: ~.\nThe next sentence is in GB.\xe5\xb7\xb1\xe6\x89\x80\xe4\xb8\x8d\xe6\xac\xb2\xef\xbc\x8c\xe5\x8b\xbf\xe6\x96\xbd\xe6\x96\xbc\xe4\xba\xba\xe3\x80\x82Bye.'
>>> u8.decode() == hz.decode('HZ')
True

However, I have no idea what the hz codec is doing with the shifted byte pairs between '~{' and '~}' All the gb codecs decode b'<:Ky2;S{#,NpJ)l6HK!#' to '<:Ky2;S{#,NpJ)l6HK!#' (ie, ascii chars to same unicode chars). And they encode '??????????' to bytes with the high bit set.

I figured it out. The 1995 rfc says "A GB (GB1 and GB2) code is a two byte code, where the first byte is in the range $21-$77   (hexadecimal), and the second byte is in the range $21-$7E." This was in the days of for 7-bit bytes, at least for safe transmission. Now that we use 8-bit bytes nearly everywhere, the gb specs have probably be updated since 1980. This makes hz rather obsolete, since high-bit unset ascii codes and high-bit set gb codes can be mixed without the hz wrapping. In any case, Python's gb codecs act this way. So the hz codec is setting and unsetting the high bit when passing bytes to and from gb codec (assuming it does not use a modified version internally).
>>> hhz = [c - 128 for c in '??????????'.encode('GB2312')]
>>> bytes(hhz)
b'<:Ky2;S{#,NpJ)l6HK!#'

Perhaps there should be a separate test like the above to be sure that hz really uses GB2312-80, as specified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 22:27:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 May 2011 20:27:58 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305145678.4.0.509766862645.issue12057@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg135802

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 11 22:50:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 11 May 2011 20:50:45 +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: <20110511204726.GA41769@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ouch, ouch, ouch!!
I'll have to send 11877.7.diff which extends 11877.6.diff.
This is necessary because using fcntl(2) with F_FULLFSYNC may fail
with ENOTTY (inapprobiate ioctl for device) in situations where
a normal fsync(2) succeeds (e.g. STDOUT_FILENO).
By the way - i have no idea of Redmoondian Horror at all
(except for http://msdn.microsoft.com/en-us/sync/bb887623.aspx).

Dropping .5 and .6 - and sorry for the noise.
Good night, Europe.

----------
Added file: http://bugs.python.org/file21973/11877.7.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
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,15 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   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
+   wether 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.  The optional *full_fsync*
+   argument can be used to enforce usage of these special functions if that is
+   approbiate for the *fd* in question.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2121,13 +2121,50 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_fsync=False)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"full_fsync forces flush of disk caches in case fsync() alone is not enough.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    PyObject *fdobj;
+    int full_fsync = 0;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        return NULL;
+
+    /* See issue 11877 discussion */
+# if ((defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC))
+    if (full_fsync != 0) {
+        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 descriptors, be on the
+         * safe side and test for inapprobiate ioctl errors */
+        res = fcntl(fd, F_FULLFSYNC);
+        if (res < 0 && errno == ENOTTY)
+            res = fsync(fd);
+#  elif defined __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0)
+            return posix_error();
+        Py_INCREF(Py_None);
+        return Py_None;
+    } else
+# endif
+        return posix_fildes(fdobj, fsync);
 }
 #endif /* HAVE_FSYNC */
 
@@ -9472,7 +9509,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Wed May 11 22:53:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 20:53:03 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <1305147183.89.0.970992404469.issue12049@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ssl_rand.patch adds RAND_bytes() and RAND_pseudo_bytes() functions to the ssl module.

I moved /dev/urandom to /dev/urandom.xxx and /dev/random to /dev/random.xxx to test RAND_bytes() error path. In this case, RAND_pseudo_bytes() generates non-cryptographic pseudo-random bytes.

RAND_pseudo_bytes() returns a tuple (bytes, is_cryptographic).

In test_ssl, I used the assertion that RAND_pseudo_bytes() only generates cryptographic numbers if RAND_status() is 1. If the assertion is wrong, the test can be changed to just test the type of is_crytographic.

RAND_bytes() and RAND_pseudo_bytes() raise a SSLError on error using ERR_get_errno() as the error code, whereas other ssl functions uses a value of the py_ssl_error enum. I don't know if it is the good choise.

----------
keywords: +patch
Added file: http://bugs.python.org/file21974/ssl_rand_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Wed May 11 22:53:26 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 11 May 2011 20:53:26 +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: <1305147206.37.0.198387424483.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21924/11877.5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed May 11 22:53:34 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 11 May 2011 20:53:34 +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: <1305147214.39.0.399419791003.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21953/11877.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed May 11 23:00:50 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 11 May 2011 21:00:50 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305147650.12.0.855652831642.issue9971@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

I've attached the latest changes based on feedback (issue9971-v5.patch)


for i in 1 4 128 256 1024 2048 4069 8192 16384; do echo -n "buffer_size=$i "; ./python -m timeit -s "f=open('LICENSE','rb');b=bytearray($i)" "f.seek(0)" "while f.readinto(b): pass"; done
buffer_size=1 100 loops, best of 3: 3.96 msec per loop
buffer_size=4 1000 loops, best of 3: 1.12 msec per loop
buffer_size=128 10000 loops, best of 3: 40.1 usec per loop
buffer_size=256 10000 loops, best of 3: 24.1 usec per loop
buffer_size=1024 100000 loops, best of 3: 12.2 usec per loop
buffer_size=2048 100000 loops, best of 3: 10.4 usec per loop
buffer_size=4069 100000 loops, best of 3: 9.52 usec per loop
buffer_size=8192 100000 loops, best of 3: 6.04 usec per loop
buffer_size=16384 100000 loops, best of 3: 4.8 usec per loop

----------
Added file: http://bugs.python.org/file21975/issue9971-v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Wed May 11 23:20:53 2011
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Wed, 11 May 2011 21:20:53 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1305148853.2.0.515505220895.issue1028@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

r70039 3.1 forward ported > 3.2 > default.  Will be in 3.2.1.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed May 11 23:48:14 2011
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Wed, 11 May 2011 21:48:14 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1305150494.58.0.990910105318.issue1028@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Having a modified utf-8 codec will be useful.  That said, it is an error
for Tcl/Tk to expose modified utf-8 externally, and that was fixed at
some point in Tk8.5.  Since Tk is no longer sending 0xC080 for the %A
char, switching codecs in _tkinter.c won't accomplish anything.

This fix was to correct a long-standing problem in IDLE using Tk8.4,
which is most easily solved by catching the leaked invalid null in
_tkinter.c.

It seems to me that, once you switch to modified utf-8 and allow the
embedded nulls, you have to make sure everything you are doing uses
the modified utf-8 encoding/decoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Wed May 11 23:57:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 21:57:42 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If a real time signal is raised 2 times whereas the signal is blocked, unblock the signal will call the signal handler twice. The C signal handler of the Python signal module only stores a boolean to say if the Python signal handler should be called or not in Py_CheckSignals().

If the C signal handler is called twice, the Python signal handler is only called once.

Attached patch is a draft to fix this issue. The patch is not completly safe.

----------
components: Interpreter Core
files: rt_signal.patch
keywords: patch
messages: 135808
nosy: haypo
priority: normal
severity: normal
status: open
title: Python doesn't support real time signals
versions: Python 3.3
Added file: http://bugs.python.org/file21976/rt_signal.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Wed May 11 23:58:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2011 21:58:36 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305151116.04.0.300022583183.issue12060@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

example.py: example to demonstrate the problem. The Python signal handler is only called once, it should be called twice.

----------
Added file: http://bugs.python.org/file21977/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 00:07:18 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 11 May 2011 22:07:18 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305151638.94.0.98691684866.issue12060@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/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 00:33:07 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 11 May 2011 22:33:07 +0000
Subject: [issue12061] Remove duplicate 'key functions' entry in Glossary
In-Reply-To: <1305153187.55.0.682645049185.issue12061@psf.upfronthosting.co.za>
Message-ID: <1305153187.55.0.682645049185.issue12061@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, only on 2.7 there were 2 entries for 'key function': this patches remove the second occurrence, leaving that part of Glossary equals to the other branches.

----------
assignee: docs at python
components: Documentation
files: remove_duplicate_key_functions-2.7.patch
keywords: patch
messages: 135810
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Remove duplicate 'key functions' entry in Glossary
versions: Python 2.7
Added file: http://bugs.python.org/file21978/remove_duplicate_key_functions-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12061>
_______________________________________

From report at bugs.python.org  Thu May 12 01:59:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2011 23:59:51 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <E1QKJJl-0006yS-CX@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a1d77c6f4ec1 by Antoine Pitrou in branch 'default':
Issue #9971: Write an optimized implementation of BufferedReader.readinto().
http://hg.python.org/cpython/rev/a1d77c6f4ec1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Thu May 12 02:02:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 00:02:34 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305158554.31.0.999112606628.issue9971@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed a minimally modified version of the patch, thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Thu May 12 02:10:00 2011
From: report at bugs.python.org (Hyeshik Chang)
Date: Thu, 12 May 2011 00:10:00 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305159000.69.0.677379244969.issue12057@psf.upfronthosting.co.za>


Hyeshik Chang <hyeshik at gmail.com> added the comment:

Hello, everyone!

The rationale why I chose to encode the test strings into a Python source code was that I wanted for them to be treated as text files which are trackable in CVS or subversion and to keep Python source codes free of any non-ASCII characters. Now I don't feel the need of "text file" status, STINNER's suggestion works for me.

Actually, all "stateful" encodings supported by cjkcodecs lack of adequate test codes. (There are seven more iso-2022 stateful encodings in addition of hz in Python.)  "cjkencoding_tests.py" is used for random chunk coding tests and most stateful encodings are not compatible with random chunk coding. For those reasons, I didn't include test strings for them there. But they apparently still need appropriate simple string coding and stream coding tests.

STINNER Victor wrote:
> I don't understand why different texts are used. Why not just using the
> same original text for all testcases? One reason can be that some
> encodings (e.g. ISO 2202) use escape sequences to change the current
> encoding. Or maybe because the characters are different (chinese vs
> japanese characters?).

Almost every encoding in cjkcodecs has different set of characters. They support different languages (Chinese, Japanese, Korean), different scripts (Hanja, Kanji, Traditional and Simplified Chinese), different standards (johab and KS X 1001 in Korean), different versions/variants (JIS X 0201 and JIS X 0213 in Japanese).  It would be quite striking, actually one of them, gb18030, is a "superset" of the Unicode so far.


Teddy J Reedy wrotes:
> Perhaps there should be a separate test like the above to be sure that hz really uses GB2312-80, as specified.

You're right.


By the way, my previous e-mail address <perky at FreeBSD.org> isn't reachable anymore, please send to <hyeshik at gmail.com> when you need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Thu May 12 06:42:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2011 04:42:24 +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: <E1QKNjC-000174-Jh@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7a3f3ad83676 by Gregory P. Smith in branch 'default':
- Issue #12044: Fixed subprocess.Popen when used as a context manager to
http://hg.python.org/cpython/rev/7a3f3ad83676

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Thu May 12 07:20:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2011 05:20:59 +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: <E1QKOKX-0003JY-LJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b00a64a5cb93 by Gregory P. Smith in branch '3.2':
merge - 7a3f3ad83676  Fixes Issue #12044.
http://hg.python.org/cpython/rev/b00a64a5cb93

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Thu May 12 07:23:31 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 12 May 2011 05:23:31 +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: <1305177811.88.0.284314866989.issue12044@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

did my commits in the reverse order (default before 3.2), oops.  this is fixed.  this wasn't ever in 2.7 so no need for the documentation note.  i'm not worried about adding a note about 3.2.0 vs 3.2.1 beyond the mention in Misc/NEWS as this was new in 3.2.0 and fixing this behavior is a pretty clear bug fix.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Thu May 12 07:45:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 05:45:17 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305179117.01.0.0869907178118.issue5723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch refactors the tests to use import_fresh_module and different subclasses for Python and C tests.
It also includes a fix to import_fresh_module to make it work with packages (it can be committed separately).

----------
assignee: bob.ippolito -> ezio.melotti
keywords: +needs review, patch
stage: test needed -> commit review
versions: +Python 3.2, Python 3.3 -Python 2.6
Added file: http://bugs.python.org/file21979/issue5723.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Thu May 12 07:47:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2011 05:47:12 +0000
Subject: [issue12061] Remove duplicate 'key functions' entry in Glossary
In-Reply-To: <1305153187.55.0.682645049185.issue12061@psf.upfronthosting.co.za>
Message-ID: <E1QKOju-0004oV-Lb@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 534a9e274d88 by Georg Brandl in branch '2.7':
#12061: remove duplicate glossary entry.
http://hg.python.org/cpython/rev/534a9e274d88

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12061>
_______________________________________

From report at bugs.python.org  Thu May 12 07:47:28 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 12 May 2011 05:47:28 +0000
Subject: [issue12061] Remove duplicate 'key functions' entry in Glossary
In-Reply-To: <1305153187.55.0.682645049185.issue12061@psf.upfronthosting.co.za>
Message-ID: <1305179248.6.0.848113280659.issue12061@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the patch!

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12061>
_______________________________________

From report at bugs.python.org  Thu May 12 07:48:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 05:48:09 +0000
Subject: [issue12058] Minor edits to comments in faulthandler
In-Reply-To: <1305132700.94.0.64826444937.issue12058@psf.upfronthosting.co.za>
Message-ID: <1305179289.12.0.144019481852.issue12058@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12058>
_______________________________________

From report at bugs.python.org  Thu May 12 07:51:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 05:51:48 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305179508.68.0.729868464798.issue8824@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In 3.x exec is a function, so the reference to 'in' should be removed/updated.  On 2.x it might be better to just use ``in`` instead of :keyword:`in`, because the latter probably links to the 'in' operator that checks for containment.

----------
nosy: +ezio.melotti
stage:  -> patch review
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Thu May 12 08:10:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 06:10:15 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1305180615.61.0.365793729674.issue12042@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The workflow to prepare a patch using Mercurial is pretty much the same as SVN:

# get a clone (checkout) of the repository
hg clone http://hg.python.org/cpython 
# select the branch where you want to fix the issue
hg update 2.7
# make changes on the file(s) and make a patch
hg diff > issue12042.diff

See also http://docs.python.org/devguide/setup.html
Also note that 2.6 only receives security fixes, so it can't be fixed there.  All the "whatsnew" files are also included in the following  versions though, so it might be worth preparing a patch against 2.7.

----------
nosy: +ezio.melotti
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Thu May 12 09:29:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 12 May 2011 07:29:46 +0000
Subject: [issue11888] Add C99's log2() function to the math library
In-Reply-To: <1303315132.33.0.304023866846.issue11888@psf.upfronthosting.co.za>
Message-ID: <1305185386.0.0.221583554202.issue11888@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11888>
_______________________________________

From report at bugs.python.org  Thu May 12 10:37:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 08:37:52 +0000
Subject: [issue9971] Optimize BufferedReader.readinto
In-Reply-To: <1285687142.56.0.374488173842.issue9971@psf.upfronthosting.co.za>
Message-ID: <1305189472.34.0.424646143831.issue9971@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You don't want to backport the optimization to at least 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9971>
_______________________________________

From report at bugs.python.org  Thu May 12 12:43:36 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 12 May 2011 10:43:36 +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: <20110512104327.GA77093@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Just adding more notes on that by reactivating one of haypo's
links from #8604.  (And: maybe some Linux documentation should be
updated?)  From Theodore Ts'o,
http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don?t-fear-fsync:

    As the Eat My Data presentation points out very clearly, the only
    safe way according that POSIX allows for requesting data written
    to a particular file descriptor be safely stored on stable storage
    is via the fsync() call.  Linux?s close(2) man page makes this
    point very clearly:

    A successful close does not guarantee that the data has been
    successfully saved to disk, as the kernel defers writes. It is not
    common for a file system to flush the buffers when the stream is
    closed. If you need to be sure that the data is physically stored
    use fsync(2).

    Why don?t application programmers follow these sage words?  These
    three reasons are most often given as excuses:

    - (Perceived) performance problems with fsync()
    - The application only needs atomicity, but not durability
    - The fsync() causing the hard drive to spin up unnecessarily in
      laptop_mode

(Don't ask me why i'm adding this note though.
I should have searched for it once i've opened that issue?
Bah!!!  Ts'o did not write that article for me.  He'd better hacked.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu May 12 13:14:47 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 12 May 2011 11:14:47 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305198887.98.0.58652960551.issue12060@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Dunno.

> The patch is not completely safe.

Yeah it will not work without atomic ops.
Unfortunately the C standart seems to go into a direction
noone understands - as if a atomic_compare_and_swap() would
not suffice!  Do you know any machine language which reflects
what that standart draft describes?  I don't.

The NSIG detection of Modules/signalmodule.c uses 64 as a fallback.
32 seems to be more reasonable.
And you test against it instead of RTMAX in the patch.
(signalmodule.c also exports Python constants RTMIN and RTMAX
even though the standart explicitely allows these values to
be non-constants;
 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html; last time i've done anything on signals - in 2005 - that was
used nowhere - Linux, FreeBSD - though.)

Often there is a huge whole in between NSIG and RTMIN, but
struct Handlers is 8 or 12 bytes (unless the compiler does the
alignment - ouuh), so 32 unused members in Handlers[] will not
cost the world anyway; on Mac OS X (no RTSIG support?!? ;)
Python is at least 6 megabytes of memory anyway.

And does anyone actually know why the last time i looked after this
(on Linux, then) realtime signals had a default action EQ SIGABRT?
Armchair crouchers...

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 13:31:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 11:31:54 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305199914.15.0.548218427237.issue5723@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Comments:
- I don't like the fact that skip_unless_cjson() uses unittest internals. Why can't you write something like:
   skip_unless_cjson = skipUnless(...)

- instead of "self.mod", "self.json" would be nicer

- you could also export "self.loads", "self.dumps" for easier access

- you could also have two base classes exporting all this instead of repeating the attribute-setting for every test class

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Thu May 12 14:32:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 12:32:39 +0000
Subject: [issue12059] hashlib does not handle missing hash functions correctly
In-Reply-To: <1305140359.29.0.351905173932.issue12059@psf.upfronthosting.co.za>
Message-ID: <1305203559.89.0.826246784729.issue12059@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12059>
_______________________________________

From report at bugs.python.org  Thu May 12 14:34:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 12:34:22 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305203662.32.0.855566368792.issue12060@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it a theoretical concern or does it affect real software?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 14:37:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 12:37:00 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305203820.56.0.476777183383.issue12060@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is it a theoretical concern or does it affect real software?

It's more theoretical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 14:47:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 12:47:43 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305204463.81.0.983075088463.issue12060@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Yeah it will not work without atomic ops.

... Or we can maybe block the signals (all signals or just one signal?) using pthread_sigmask(SIG_BLOCK) while we access the Handlers array. But pthread_sigmask() is not available on all OSes.

On my Linux box, Python 3.3 says that signal.NSIG is equal to 65 which looks correct.

> does anyone actually know why the last time i looked after this
> (on Linux, then) realtime signals had a default action EQ SIGABRT?

The manpage says "The default action for an unhandled real-time signal is to terminate the receiving process." It is an arbitrary choice. Why do you care about the default action?

> The NSIG detection of Modules/signalmodule.c uses 64 as a fallback.
> 32 seems to be more reasonable.
> And you test against it instead of RTMAX in the patch.

I don't understand: I don't use RTMAX in my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 15:07:28 2011
From: report at bugs.python.org (Genstein)
Date: Thu, 12 May 2011 13:07:28 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>


New submission from Genstein <pythondev at genstein.net>:

Reporting this as requested by Antoine Pitrou: Under certain circumstances in Python 3.2 (r32:88445) it's possible for buffered I/O to lose data before it is written and/or return the wrong results when reading. I tripped over this issue whilst writing an assembler which first writes out a bunch of binary data and then goes back over it in a somewhat arbitrary order patching addresses.

The following code demonstrates the issue:

[code]
START = 0
MID = 1
LENGTH = 4

def test(buffering):
    f = open("test.bin", "w+b", buffering = buffering)
    for i in range(LENGTH):
        f.write(b'\x00')
    f.seek(MID)
    f.read(1)
    f.write(b'\x00')
    f.seek(MID)
    f.write(b'\x01')
    f.seek(START)
    f.seek(MID)
    print(f.read(1))
    f.close()

print("Buffered result: ")
test(-1)
print("Unbuffered result:")
test(0)
[end code]

Output on both Gentoo and Vista is:
    Buffered result:
    b'\x00'
    Unbuffered result:
    b'\x01'

Expected output is b'\x01' in both cases.

The issue is reproducible with larger files provided that the constants are increased ~proportionally (START 0, MID 500, LENGTH 1000 for example). Transposing the buffered/unbuffered tests and/or using different buffer sizes for the buffered test seem have no effect. 

The lengthy code at this URL also demonstrates the issue: http://pastebin.com/xqrzKr5D The above was produced from this code, which was autogenerated by intercepting my assembler's output.

----------
components: IO
messages: 135830
nosy: genstein
priority: normal
severity: normal
status: open
title: Buffered I/O inconsistent with unbuffered I/O in certain cases
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Thu May 12 15:25:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 13:25:27 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305206727.21.0.0304291304518.issue12062@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If you add "from _pyio import open" to the example, unbuffered and buffered tests give the same result :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Thu May 12 15:29:04 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 12 May 2011 13:29:04 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305204463.81.0.983075088463.issue12060@psf.upfronthosting.co.za>
Message-ID: <20110512132855.GA31022@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> On my Linux box, Python 3.3 says that signal.NSIG is equal to 65
> which looks correct.

On FreeBSD NSIG only counts "old" signals (32, one 32 bit mask),
SIGRTMIN is 65 and SIGRTMAX is 126.
Our internal old signal.h states

        * If we do have realtime signals, #rtmin is 35 (i.e.,
        * #nsig, FreeBSD+) or something like 38 or even 40 (Linux),
        * and #rtmax is most likely 64 (Linux) or 128 (FreeBSD+).

so that this seems to be somewhat constant in time.
(#rtmin: we take some of those RT sigs for internal purposes if
possible.  This was maybe a bad and expensive design decision.)

> Why do you care about the default action?

* \brief Hooking program crashes (\psa crash.h crash.h\epsa).
* \note
* Installed hooks (normally) execute from within an internal
* signal handler!

So many syscalls for things which don't matter almost ever.
And that may even cost context-switches sometimes.

> I don't understand: I don't use RTMAX in my patch.

+    for (signum = 1; signum < NSIG; signum++) {

This will not catch the extended signal range on FreeBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 15:39:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 13:39:13 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305207553.23.0.448988859664.issue12062@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch with assorted tests.

----------
keywords: +patch
nosy: +barry, benjamin.peterson, georg.brandl, pitrou
priority: normal -> release blocker
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.3
Added file: http://bugs.python.org/file21980/bufbug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Thu May 12 15:45:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 13:45:20 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305207920.94.0.792352031022.issue12062@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

open("test.bin", "w+b", buffering=-1) creates a 
BufferedRandom object. In the _pyio module, BufferedRandom overrides the write() method to "undo readahead", whereas the _io module reuses bufferedwriter_write() for bufferedrandom_methods and bufferedwriter_methods.

I suppose that the problem is "just" that _io.BufferedRandom.write() doesn't undo readahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Thu May 12 15:53:23 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 12 May 2011 13:53:23 +0000
Subject: [issue3974] collections.namedtuple uses exec to create new classes
In-Reply-To: <1222430514.93.0.950826754089.issue3974@psf.upfronthosting.co.za>
Message-ID: <1305208403.82.0.519378159824.issue3974@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, exec is unholy:)

For embedding Python into a console game we have removed the python compiler.  exec and eval don't work.  This saves space and is also a security feature.  I had to modify the collections module so that namedtuple() just returns tuple.  Fortunately, no part of the standard library that uses namedtuple actually uses the actual names, everyone just uses it as a tuple.  So that approach works.

Another problem with the Eval approach is code duplication.

A third could arguably be that there is no namedtuple base class.

Now, replacing namedtuples with tuples works in the standardlib _currentlyt_, but I'm happy to have found an alternative implementation, for future safety.  I only wish it were not hidden away as a diff in a feature request.

----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3974>
_______________________________________

From report at bugs.python.org  Thu May 12 16:10:30 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 12 May 2011 14:10:30 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305209430.29.0.679554507231.issue12062@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/issue12062>
_______________________________________

From report at bugs.python.org  Thu May 12 16:19:30 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 12 May 2011 14:19:30 +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: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

Tokenizing `' 1 2 3` versus `''' 1 2 3` yields different results.

Tokenizing `' 1 2 3` gives:

1,0-1,1:	ERRORTOKEN	"'"
1,2-1,3:	NUMBER	'1'
1,4-1,5:	NUMBER	'2'
1,6-1,7:	NUMBER	'3'
2,0-2,0:	ENDMARKER	''

while tokenizing `''' 1 2 3` yields:

Traceback (most recent call last):
  File "prog.py", line 4, in <module>
    tokenize.tokenize(iter(["''' 1 2 3"]).next)
  File "/usr/lib/python2.6/tokenize.py", line 169, in tokenize
    tokenize_loop(readline, tokeneater)
  File "/usr/lib/python2.6/tokenize.py", line 175, in tokenize_loop
    for token_info in generate_tokens(readline):
  File "/usr/lib/python2.6/tokenize.py", line 296, in generate_tokens
    raise TokenError, ("EOF in multi-line string", strstart)
tokenize.TokenError: ('EOF in multi-line string', (1, 0))


Apparently tokenize decides to re-tokenize after the erroneous quote in the case of a single-quote, but not a triple-quote. I guess that this is because retokenizing the rest of the file after an unclosed triple-quote would be expensive; however, I've also been told it's very strange and possibly wrong for tokenize to be inconsistent this way.

If this is the right behavior, I guess I'd like it if it were documented. This sort of thing is confusing / potentially misleading for users of the tokenize module. Or at least, when I saw how single quotes were handled, I assumed incorrectly that all quotes were handled that way.

----------
messages: 135836
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: tokenize module appears to treat unterminated single and double-quoted strings inconsistently

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12063>
_______________________________________

From report at bugs.python.org  Thu May 12 16:22:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 14:22:06 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305210126.04.0.954778843464.issue12048@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Thu May 12 16:33:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 14:33:52 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305210832.86.0.599796222253.issue12048@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This is a duplicate of #10801, issue fixed in Python 3.2 or later by 33543b4e0e5d. Should we backport the fix to Python 3.1, or you can upgrade to Python 3.2?

Output with Python 3.2: "???? test.txt".

----------
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Thu May 12 16:34:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 14:34:44 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305210884.79.0.599445847643.issue12048@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Library (Lib), Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Thu May 12 16:35:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 14:35:17 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305210917.99.0.993027360004.issue12048@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Thu May 12 16:35:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 14:35:48 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1305210948.43.0.43296723757.issue10801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #12048 is a duplicate of this bug, but with Python 3.1. Should we backport the fix to Python 3.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Thu May 12 16:38:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 14:38:31 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305211111.82.0.16868533819.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I wanted for them to be treated as text files which are trackable
> in CVS or subversion and to keep Python source codes free of any
> non-ASCII characters

Mercurial supports binary file, I plan to mark the CJK testcases as binary using .hgeol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Thu May 12 16:48:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 12 May 2011 14:48:16 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305211696.23.0.143525631687.issue12048@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But according to the initial report, 3.2 does not give the expected behavior. This zip file actually stores the filename encoded with cp932, which is incorrect according to the specifications of the ZIP format (only cp437 and utf8 are valid)

See issue10614 for a possible solution: allow users to specify an alternate encoding to handle such invalid files.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Thu May 12 16:48:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2011 14:48:28 +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: <E1QKXBi-00082n-OT@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 361f87c8f36a by ?ukasz Langa in branch 'default':
Cleaned up a backward merge after fixes issue #12044.
http://hg.python.org/cpython/rev/361f87c8f36a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12044>
_______________________________________

From report at bugs.python.org  Thu May 12 17:07:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 15:07:38 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305212858.59.0.672613125471.issue12048@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, right.

Note: the encoding looks to be GBK, not CP932:

>>> '\u590d\u4ef6'.encode('gbk')
b'\xb8\xb4\xbc\xfe'
>>> '\u590d\u4ef6'.encode('gbk').decode('cp437')
'????'
>>> '\u590d\u4ef6'.encode('cp932')
...
UnicodeEncodeError: 'cp932' codec can't encode character '\u590d' ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Thu May 12 17:44:20 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 12 May 2011 15:44:20 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305215060.47.0.533728660662.issue8824@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


Removed file: http://bugs.python.org/file21961/exec_doc_touchup_3_x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Thu May 12 17:44:34 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 12 May 2011 15:44:34 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305215074.89.0.214833307736.issue8824@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


Added file: http://bugs.python.org/file21981/exec_doc_touchup_3.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Thu May 12 18:00:38 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 12 May 2011 16:00:38 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305216038.61.0.807272717059.issue8824@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


Added file: http://bugs.python.org/file21982/exec_doc_touchup_2.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Thu May 12 18:04:31 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 12 May 2011 16:04:31 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305216271.36.0.717786267185.issue8824@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

I've updated the 3.x patch, should be correct now.

I also updated the 2.x patch to use ``in``. :keyword:`in` was used in an earlier part of the paragraph I modified, so I have changed both for consistency.

This is the paragraph before modification:
"
  In all cases, if the optional parts are omitted, the code is executed in the
  current scope.  If only the first expression after :keyword:`in` is specified,
  it should be a dictionary, which will be used for both the global and the local
  variables.  If two expressions are given, they are used for the global and local
  variables, respectively. If provided, *locals* can be any mapping object.
"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Thu May 12 18:04:56 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 12 May 2011 16:04:56 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1305216296.97.0.104276308814.issue8824@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


Removed file: http://bugs.python.org/file21960/exec_doc_touchup_2_x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Thu May 12 18:18:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 16:18:42 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>
Message-ID: <1305217122.59.0.820210722215.issue12040@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch addressing Gregory's comment (retry select() on EINTR).

----------
Added file: http://bugs.python.org/file21983/process_sentinel2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12040>
_______________________________________

From report at bugs.python.org  Thu May 12 19:29:03 2011
From: report at bugs.python.org (Ron Ridley)
Date: Thu, 12 May 2011 17:29:03 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1305221343.67.0.102867063561.issue10713@psf.upfronthosting.co.za>


Changes by Ron Ridley <ronster76 at gmail.com>:


----------
nosy: +Ron.Ridley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Thu May 12 19:32:20 2011
From: report at bugs.python.org (John O'Connor)
Date: Thu, 12 May 2011 17:32:20 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305221540.3.0.971564570848.issue12062@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Thu May 12 19:52:56 2011
From: report at bugs.python.org (Mathias Svensson)
Date: Thu, 12 May 2011 17:52:56 +0000
Subject: [issue12064] unexpected behavior with exception variable
In-Reply-To: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>
Message-ID: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>


New submission from Mathias Svensson <freaken at freaken.dk>:

Current behavior:
In the very simple attached example an existing variable-name is used as the target in the except-part of a try-statement. The existing variable is deleted if an exception is throw.

Excepted behavior:
The only reasonable behaviors are keeping the original variable or keeping the exception. The current behavior is very unintuitive.

----------
components: Interpreter Core
files: test.py
messages: 135845
nosy: Mathias.Svensson
priority: normal
severity: normal
status: open
title: unexpected behavior with exception variable
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file21984/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12064>
_______________________________________

From report at bugs.python.org  Thu May 12 20:04:41 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 12 May 2011 18:04:41 +0000
Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile
In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>
Message-ID: <1305223481.88.0.97141389292.issue12018@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Attaching a patch to test a use case for ntpath.samefile (looks like sameopenfile is already tested--or at least a use case of it).

----------
components: +Library (Lib)
keywords: +patch
nosy: +santa4nt
versions:  -Python 3.4
Added file: http://bugs.python.org/file21985/test_samefile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12018>
_______________________________________

From report at bugs.python.org  Thu May 12 20:14:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 12 May 2011 18:14:37 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <20110512104327.GA77093@sherwood.local>
Message-ID: <BANLkTikjJbCnh9gVzEKpfZ4LjM8F0ZLhzA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Calling fsync on a file descriptor referring to a tty doesn't make much sense.
On Linux, this fails with EINVAL:
$ python -c 'import os; os.fsync(1)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 22] Invalid argument

So if the full sync fails on ttys, it shouldn't be a problem: since
the default performs a classical fsync, this won't break compatibility
with existing code anyway.
So I think you should stick with the previous version (well, if the
full sync fails on other FDs, then it's another story, but in that
case it should just be dropped altogether if it's not reliable...).

By the way, it's "appropriate", not "approbiate". You made the same
typo in your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu May 12 20:16:02 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 12 May 2011 18:16:02 +0000
Subject: [issue12064] unexpected behavior with exception variable
In-Reply-To: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>
Message-ID: <1305224162.27.0.367131579503.issue12064@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Duplicate of issue8130.

"When an exception has been assigned using as target, it is cleared at the end of the except clause." [1]

See: 
[1] http://docs.python.org/py3k/reference/compound_stmts.html#the-try-statement
[2] http://www.python.org/dev/peps/pep-3110/#semantic-changes (discussed in issue4617)

----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12064>
_______________________________________

From report at bugs.python.org  Thu May 12 20:16:36 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 12 May 2011 18:16:36 +0000
Subject: [issue12064] unexpected behavior with exception variable
In-Reply-To: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>
Message-ID: <1305224196.4.0.62063654761.issue12064@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Looks like a regression from 2.x.

On 2.7:
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.
>>> e = True
>>> try: raise Exception()
... except Exception as e: pass
...
>>> print repr(e)
Exception()

On 3.2:
Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> e = True
>>> try: raise Exception()
... except Exception as e: pass
...
>>> print(repr(e))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'e' is not defined

----------
nosy: +santa4nt
versions: +Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12064>
_______________________________________

From report at bugs.python.org  Thu May 12 20:22:29 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 12 May 2011 18:22:29 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305224549.93.0.610811009555.issue6727@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/issue6727>
_______________________________________

From report at bugs.python.org  Thu May 12 20:26:26 2011
From: report at bugs.python.org (Milko Krachounov)
Date: Thu, 12 May 2011 18:26:26 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1305224786.83.0.480514790076.issue8604@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

I have a class for overwriting files "properly" that I use in three of my projects. It aims to be atomic as possible, supports creating backups, but it doesn't have functions to set or retain permissions when requested (which might be desirable if such a function is added to stdlib). I'd give it here for reference and ideas.

- It's a context manager acting like a normal file object so you can use it with e.g. json.dump. In CM mode, if an error is caught, you end up with the old file automatically. If you use it as a file, the 'close' method has a 'cancel' argument to achieve the same.
- Normal overwrite on POSIX uses flush, fsync, rename as it should.
- Since fsync doesn't work on Mac OS X, it takes care of calling the Mac OS X specific F_FULLFSYNC fcntl.
- On POSIX, if a backup is requested, an attempt is made to do it with a hardlink, otherwise do two renames (killing the atomicity). Maybe a copy with shutil would be a better choice though.
- On Windows it uses two renames - the old file is backed up to a temporary name, and then the new file is renamed over it. If a backup wasn't requested, the temporary name is deleted.

I also have a simple unit test for it, but I've ran it on POSIX only.

Here's the part of the code that does the open/close part:
http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/61/blackherd/misc.py#L498

And the unit test:
http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/61/tests/test_misc.py#L473

I hope that's useful.

----------
nosy: +milko.krachounov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu May 12 20:27:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 18:27:47 +0000
Subject: [issue12064] unexpected behavior with exception variable
In-Reply-To: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>
Message-ID: <1305224867.4.0.0962210457715.issue12064@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Closing as duplicate.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12064>
_______________________________________

From report at bugs.python.org  Thu May 12 20:33:12 2011
From: report at bugs.python.org (Milko Krachounov)
Date: Thu, 12 May 2011 18:33:12 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1305225192.27.0.25563393057.issue8604@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

Well, since I had a typo in the main method which called the Windows implementation on POSIX, the unit test works on the code for Windows when ran on POSIX. Heh, I'm sorry for the noise, but it seems that re-reading the code four times and running the unit tests is not enough, corrected revision:

http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/62/blackherd/misc.py#L498

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Thu May 12 21:33:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2011 19:33:13 +0000
Subject: [issue12065] test_ssl failure when svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

See

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.2/builds/34/steps/test/logs/stdio

Antoine says that connect_ex should be returning an error, not None, in that situation.

----------
components: Tests
keywords: buildbot
messages: 135853
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ssl failure when svn.python.org fails to resolve
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12065>
_______________________________________

From report at bugs.python.org  Thu May 12 21:33:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 19:33:39 +0000
Subject: [issue12065] test_ssl failure when svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <1305228819.54.0.93758741864.issue12065@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12065>
_______________________________________

From report at bugs.python.org  Thu May 12 21:37:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2011 19:37:03 +0000
Subject: [issue11896] Save on Close fails in IDLE, from Linux system
In-Reply-To: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>
Message-ID: <E1QKbh0-0001Ar-8u@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset da7a120c0478 by Kurt B. Kaiser in branch '3.1':
Issue #11896: Save on Close failed despite selecting "Yes" in dialog.
http://hg.python.org/cpython/rev/da7a120c0478

New changeset 87196154dec8 by Kurt B. Kaiser in branch 'default':
Merge from 3.2
http://hg.python.org/cpython/rev/87196154dec8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11896>
_______________________________________

From report at bugs.python.org  Thu May 12 21:37:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 19:37:11 +0000
Subject: [issue12065] test_ssl failure when svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <1305229031.34.0.731312131663.issue12065@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Judging by ssl.connect_ex's source code, this can only mean that socket.connect raised a socket error with a "None" errno...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12065>
_______________________________________

From report at bugs.python.org  Thu May 12 21:41:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 19:41:14 +0000
Subject: [issue12065] test_ssl failure when svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <1305229274.34.0.642523382123.issue12065@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Which probably means it was a socket.timeout. When called on a non-SSL socket, connect_ex() returns 11 (EAGAIN) for timeout errors:

>>> s = socket.socket()
>>> s.settimeout(0.00001)
>>> s.connect_ex(("svn.python.org", 443))
11

But on SSL sockets, connect_ex() loses the errno (because it calls connect() on the underlying socket, not connect_ex(), and socket.timeout isn't raised with an errno):

>>> s = ssl.wrap_socket(socket.socket())
>>> s.settimeout(0.00001)
>>> print(s.connect_ex(("svn.python.org", 443)))
None

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12065>
_______________________________________

From report at bugs.python.org  Thu May 12 22:01:51 2011
From: report at bugs.python.org (Nir Aides)
Date: Thu, 12 May 2011 20:01:51 +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: <1305230511.18.0.0895360934602.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Hi,

There seem to be two alternatives for atfork handlers:
1) acquire locks during prepare phase and unlock them in parent and child after fork.
2) reset library to some consistent state in child after fork.

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html

Option (2) makes sense but is probably not always applicable.
Option (1) depends on being able to acquire locks in locking order, but how can we determine correct locking order across libraries?

Initializing locks in child after fork without acquiring them before the fork may result in corrupted program state and so is probably not a good idea.

On a positive note, if I understand correctly, Python signal handler functions are actually run in the regular interpreter loop (as pending calls) after the signal has been handled and so os.fork() atfork handlers will not be restricted to async-signal-safe operations (since a Python fork is never done in a signal handler).

http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html
http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html
"It is therefore undefined for the fork handlers to execute functions that are not async-signal-safe when fork() is called from a signal handler."

Opinion by Butenhof who was involved in the standardization effort of POSIX threads:
http://groups.google.com/group/comp.programming.threads/msg/3a43122820983fde

...so how can we establish correct (cross library) locking order during prepare stage?

Nir

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu May 12 22:02:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 20:02:43 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305230563.62.0.550759975608.issue5723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Why can't you write something like:skip_unless_cjson = skipUnless(...)

This indeed works -- using unittest internals was just a temporary workaround because the example in the unittest doc didn't seem to work.

> - instead of "self.mod", "self.json" would be nicer

I thought about using self.json, but then opted for 'mod' because is what the other modules seem to use, but I will fix it.

> - you could also export "self.loads", "self.dumps" for easier access

Usually they are not called more than a couple of times for each test, and each test class usually has 1-2 tests methods, so I'm not sure it's worth it.

- you could also have two base classes exporting all this instead of repeating the attribute-setting for every test class

I considered this too, but since the C test classes currently inherit from the Python classes, the C base class would have to be a mixin that overrides the effect of the Python base class -- unless I move all the tests in separate base classes and create two separate subclasses for each C/Python test that inherit from the base test classes and either the C or Python base classes. So the two base test classes will be in __init__:
  class CTest(TestCase):
      self.json = cjson; self.loads = cjson.loads; ...
  class PyTest(TestCase):
      self.json = pyjson; self.loads = pyjson.loads; ...

and the other test files will use either:
  class TestPySomething(PyTest):
      def test_something(self): ...
  class TestCSomething(TestPySomething, CTest):
      pass

or:
  class TestSomething(TestCase):
      def test_something(self): ...
  class TestPySomething(TestSomething, PyTest): pass
  class TestCSomething(TestSomething, CTest): pass

Another option is to have a single base class that sets self.loads/dumps in the __init__ but that will still require the module to be set in the subclasses, something like:
  class JsonTestCase(TestCase):
      def __init__(self):
          self.loads = self.json.loads
          self.dumps = self.json.dumps

and then use:
  class TestPySomething(JsonTestCase):
      json = pyjson
      def test_something(self): ...
  class TestCSomething(TestPySomething):
      json = cjson

I'm not sure any of these options is better than what we have now though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Thu May 12 22:09:03 2011
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Thu, 12 May 2011 20:09:03 +0000
Subject: [issue11896] Save on Close fails in IDLE, from Linux system
In-Reply-To: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>
Message-ID: <1305230943.32.0.696225196206.issue11896@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

tkinter.messagebox.Message sending <class '_tkinter.Tcl_Obj'> rather
than str, so comparison with str failed.  Always for "cancel", (almost?)
always for "yes".

Use the helper functions in tkinter.messagebox, which correct for that.

This hasn't worked for a long time, I'm surprised it just came up.  Will
backport to 2.7.

----------
assignee: ned.deily -> kbk
nosy: +kbk
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11896>
_______________________________________

From report at bugs.python.org  Thu May 12 22:36:29 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 12 May 2011 20:36:29 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305232589.48.0.0405681232804.issue11614@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why is this still open, and more importantly, why is it a release blocker?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Thu May 12 22:37:50 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 12 May 2011 20:37:50 +0000
Subject: [issue12046] Windows build identification incomplete
In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>
Message-ID: <1305232670.62.0.82297329862.issue12046@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Martin, you're probably the only one who can fix this in reasonable time anyway.  So I'd not let it block 3.2.1.

(If all else fails, you can give the Windows build the correct identification manually, right?)

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12046>
_______________________________________

From report at bugs.python.org  Thu May 12 22:39:10 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 12 May 2011 20:39:10 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <BANLkTikjJbCnh9gVzEKpfZ4LjM8F0ZLhzA@mail.gmail.com>
Message-ID: <20110512203900.GA85022@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

[.]
> OSError: [Errno 22] Invalid argument

Sorry, i didn't know that.  Mac OS X (2.5 and 2.6 Apple shipped):

21:43 ~/tmp $ python2.5 -c 'import os; os.fsync(1)'; echo $?
0
21:43 ~/tmp $ python2.6 -c 'import os; os.fsync(1)'; echo $?
0
21:43 ~/tmp $ python2.7 -c 'import os; os.fsync(1)'; echo $?
0
21:43 ~/tmp $ python3 -c 'import os; os.fsync(1)'; echo $?
0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu May 12 22:39:19 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 12 May 2011 20:39:19 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1305232759.07.0.0340518279737.issue9516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I trust this patch does the right thing -- can you apply it before the rc this weekend?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Thu May 12 22:44:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 20:44:54 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305233094.53.0.42315386852.issue11614@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Why is this still open

Because import __hello__ doesn't print hello.

> and more importantly, why is it a release blocker?

Because it is a very important issue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Thu May 12 22:56:56 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 12 May 2011 20:56:56 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <BANLkTikjJbCnh9gVzEKpfZ4LjM8F0ZLhzA@mail.gmail.com>
Message-ID: <20110512205645.GB85022@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> So I think you should stick with the previous version (well, if the
> full sync fails on other FDs, then it's another story, but in that
> case it should just be dropped altogether if it's not reliable...).

Strong stuff.
*This* is the version which should have been implemented from the
beginning, but Apple states

 F_FULLFSYNC Does the same thing as fsync(2) then asks the drive to
             flush all buffered data to the permanent storage
             device (arg is ignored).  This is currently
             implemented on HFS, MS-DOS (FAT), and Universal Disk
             Format (UDF) file systems.

and i thought
- fsync (maybe move buffers to Queue; do reorder Queue as approbiate)
- do call fsys impl. to .. whatever
That's why i had a version of the patch which did 'fsync();fcntl();'
because it would have been an additional syscall but the fsync()
part would possibly have been essentially "skipped over" ..unless..
Linux RC scripts had 'sync && sync && sync' but it does not seem
to be necessary any more (was it ever - i don't know).

But who knows if that fcntl will fail on some non-noted fsys?
I think it's better to be on the safe side.
Quoting you, Charles-Fran??ois
> People requiring write durability will probably manage to find
> this full_sync parameter
and if they do they thus really strive for data integrity, so call
fsync() as a fallback for the security which Apple provides.
Also: we cannot let os.fsync() fail with ENOTTY!?

> By the way, it's "appropriate", not "approbiate". You made the same
> typo in your patch.

8~I  That was not a typo.  Thanks.
I'll changed that.

----------
Added file: http://bugs.python.org/file21986/11877.8.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
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_fsync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,15 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   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
+   wether 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.  The optional *full_fsync*
+   argument can be used to enforce usage of these special functions if that is
+   appropriate for the *fd* in question.
+
    Availability: Unix, and Windows.
 
 
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2121,13 +2121,50 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_fsync=False)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"full_fsync forces flush of disk caches in case fsync() alone is not enough.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    PyObject *fdobj;
+    int full_fsync = 0;
+    static char *keywords[] = {"fd", "full_fsync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_fsync))
+        return NULL;
+
+    /* See issue 11877 discussion */
+# if ((defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC))
+    if (full_fsync != 0) {
+        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 */
+        res = fcntl(fd, F_FULLFSYNC);
+        if (res < 0 && errno == ENOTTY)
+            res = fsync(fd);
+#  elif defined __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0)
+            return posix_error();
+        Py_INCREF(Py_None);
+        return Py_None;
+    } else
+# endif
+        return posix_fildes(fdobj, fsync);
 }
 #endif /* HAVE_FSYNC */
 
@@ -9472,7 +9509,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Thu May 12 22:58:44 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 12 May 2011 20:58:44 +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: <1305233924.23.0.627088489347.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21973/11877.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu May 12 23:10:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 12 May 2011 21:10:08 +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: <1305234608.14.0.318507874253.issue6721@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@Nir Aides: *thanks* for this link:
   http://groups.google.com/group/comp.programming.threads/msg/3a43122820983fde
You made my day!

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu May 12 23:11:16 2011
From: report at bugs.python.org (Atamurad Hezretkuliyev)
Date: Thu, 12 May 2011 21:11:16 +0000
Subject: [issue12066] Empty ('') xmlns attribute is not properly handled by
	xml.dom.minidom
In-Reply-To: <1305234676.35.0.0571872848833.issue12066@psf.upfronthosting.co.za>
Message-ID: <1305234676.35.0.0571872848833.issue12066@psf.upfronthosting.co.za>


New submission from Atamurad Hezretkuliyev <atamyrat at gmail.com>:

Parsing "<test xmlns=''></test>" with minidom and converting back to string raises an exception.

>>> import xml.dom.minidom
>>> xml.dom.minidom.parseString("<test xmlns=''></test>").toxml()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 45, in toxml
    return self.toprettyxml("", "", encoding)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 57, in toprettyxml
    self.writexml(writer, "", indent, newl, encoding)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 1749, in writexml
    node.writexml(writer, indent, addindent, newl)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 812, in writexml
    _write_data(writer, attrs[a_name].value)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xml/dom/minidom.py", line 301, in _write_data
    data = data.replace("&", "&amp;").replace("<", "&lt;")
AttributeError: 'NoneType' object has no attribute 'replace'
>>> 

Ii am not familiar with the XML spec so I've no idea if ignoring or accepting empty namespace is the right thing to do. If someone advices me on how it should be handled, I'd like to write a patch.

----------
components: Library (Lib)
messages: 135867
nosy: atamyrat
priority: normal
severity: normal
status: open
title: Empty ('') xmlns attribute is not properly handled by xml.dom.minidom
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12066>
_______________________________________

From report at bugs.python.org  Thu May 12 23:24:53 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 12 May 2011 21:24:53 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305235493.42.0.0444354832388.issue11614@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

A patch against 3.1. The new bytecode is now:

  1           0 LOAD_CONST               2 (True) 
              3 STORE_NAME               1 (initialized) 

  2           6 LOAD_NAME                2 (print) 
              9 LOAD_CONST               0 ('Hello world...') 
             12 CALL_FUNCTION            1 
             15 POP_TOP              
             16 LOAD_CONST               1 (None) 
             19 RETURN_VALUE

----------
keywords: +patch
Added file: http://bugs.python.org/file21987/issue11614.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Thu May 12 23:40:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 21:40:18 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305236418.87.0.0604248450178.issue11614@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+print("Hello world...")

I would prefer a more positive "Hello World!", but thanks for the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Thu May 12 23:40:30 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 12 May 2011 21:40: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: <1305236430.65.0.742599323555.issue11877@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> and if they do they thus really strive for data integrity, so call
> fsync() as a fallback for the security which Apple provides.

Why?
If I ask a full sync and it fails, I'd rather have an error returned so that I can take the appropriate decision (abort, roll-back, try a standard fsync) rather than have Python silently replace it by an fsync.

> Also: we cannot let os.fsync() fail with ENOTTY!?

Why not, since that's what the kernel returns?
Once again, since the default behaviour doesn't change, this won't break any existing application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Thu May 12 23:51:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 12 May 2011 21:51:59 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305237119.97.0.720079360847.issue12060@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> If the C signal handler is called twice, the Python signal handler is only called once.

It's not the only shortage with the current implementation regarding (real-time) signals. Another one is that they're delivered out-of-order (lowest-numbered signal first), and the most important one - especially for real-time signals - is that the handlers are executed synchronously, when Py_CheckSignals() is called.
While we can't do much about the the later, there's at least a way to handle the other issues, a small variant of the self-pipe trick:
- in the signal module initialization code, create a pipe with both ends set to non-blocking
- in the signal handler, write the signal received to the pipe (just like what's done for wakeup_fd)
- in Py_CheckSignals(), read from the pipe: the signals will be read in order, as many times as they were received. Call the handler for each signal read from the pipe.

advantages:
- it's async-safe
- signals are handled in order
- signal handlers are called the correct number of times
- you don't have to walk through the whole array of signal handlers, since you know exatly what signals have been received

drawbacks:
- might be a bit slower, because of the read syscall
- consumes 2 FDs
- have to reinit the pipe on fork
- does Windows have pipe/read/write?
- maybe overkill

But I'm really not sure that fixing this is worth it...

By the way, to be pedantic, in the current code, wakeup_fd and Handlers should be volatile, and tripped should be sig_atomic_t.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Thu May 12 23:56:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 21:56:27 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1305230563.62.0.550759975608.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305237383.3548.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

>   class TestSomething(TestCase):
>       def test_something(self): ...
>   class TestPySomething(TestSomething, PyTest): pass
>   class TestCSomething(TestSomething, CTest): pass

I was thinking about that. That looks clean and explicit to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Thu May 12 23:59:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 May 2011 21:59:34 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Current 3.2 doc, 5.9. Comparisons, has this paragraph about mixed-type comparisons.

"The operators <, >, ==, >=, <=, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, the == and != operators *always* consider objects of different types to be unequal, while the <, >, >= and <= operators raise a TypeError when comparing objects of different types that do not implement these operators for the given pair of types. You can control comparison behavior of objects of non-built-in types by defining rich comparison methods like __gt__(), described in section Basic customization."

Sentence 3: "If both are numbers, they are converted to a common type." I suspect it would be more true to say 'common internal type' as I would not think it a language requirement to produce Python objects.

In any case, I think it is only true for built-in number types, and I do not see that qualification anywhere previously.

That aside, it does not appear to be true for Decimals and Fractions in 2.7.1.

Sentence 4: first clause is only true for built-in types. That qualification is not obvious to everyone, as evidenced by a current python-list sub thread.

For 2.7, which has a different continuation, I suggest adding 'built-in' before 'objects of'.
For 3.2/3, I suggest deleting '*always*' and adding a comma after 'TypeError' so that the 'when' condition applies to equality comparisons also.

After discussion about same-type comparisons, there is another paragraph about mixed-type comparison:

"Comparison of objects of the differing types depends on whether either of the types provide explicit support for the comparison. Most numeric types can be compared with one another, but comparisons of float and Decimal are not supported to avoid the inevitable confusion arising from representation issues such as float('1.1') being inexactly represented and therefore not exactly equal to Decimal('1.1') which is. When cross-type comparison is not supported, the comparison method returns NotImplemented. This can create the illusion of non-transitivity between supported cross-type comparisons and unsupported comparisons. For example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2)."

I suggest deleting this entirely. The first sentence and first clause of the second repeat what was said above. The rest is obsolete as float/decimal comparisons *are* implemented in 2.7.1 and 3.2.0.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 135873
nosy: docs at python, rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc: remove errors about mixed-type comparisons.
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12067>
_______________________________________

From report at bugs.python.org  Fri May 13 00:02:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 22:02:12 +0000
Subject: [issue12068] test_logging failure in test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This has started popping up on several buildbots:


======================================================================
FAIL: test_rollover (test.test_logging.TimedRotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_logging.py", line 3529, in test_rollover
    self.assertTrue(found, msg=msg)
AssertionError: False is not true : No rotated files found, went back 1 seconds

(http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/101/steps/test/logs/stdio)

----------
assignee: vinay.sajip
components: Tests
messages: 135874
nosy: pitrou, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: test_logging failure in test_rollover
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12068>
_______________________________________

From report at bugs.python.org  Fri May 13 00:10:30 2011
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 12 May 2011 22:10:30 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1305238230.9.0.581961203801.issue12067@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/issue12067>
_______________________________________

From report at bugs.python.org  Fri May 13 00:19:04 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 12 May 2011 22:19:04 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305238744.01.0.995632045365.issue11614@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


Added file: http://bugs.python.org/file21988/issue11614_!.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Fri May 13 00:22:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 22:22:32 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1305238952.97.0.215682237251.issue12067@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you provide a patch?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12067>
_______________________________________

From report at bugs.python.org  Fri May 13 00:28:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2011 22:28:31 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <E1QKeMv-0006vB-OJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 89f77afac947 by Antoine Pitrou in branch '3.1':
Issue #12062: Fix a flushing bug when doing a certain type of I/O sequence
http://hg.python.org/cpython/rev/89f77afac947

New changeset 47ca1244a929 by Antoine Pitrou in branch '3.2':
Issue #12062: Fix a flushing bug when doing a certain type of I/O sequence
http://hg.python.org/cpython/rev/47ca1244a929

New changeset 05e0227e3879 by Antoine Pitrou in branch 'default':
Issue #12062: Fix a flushing bug when doing a certain type of I/O sequence
http://hg.python.org/cpython/rev/05e0227e3879

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Fri May 13 00:32:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2011 22:32:30 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <E1QKeQn-0007KN-Oi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0d24d4c537a6 by Antoine Pitrou in branch '2.7':
Issue #12062: In the `io` module, fix a flushing bug when doing a certain
http://hg.python.org/cpython/rev/0d24d4c537a6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Fri May 13 00:33:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 22:33:23 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1305239603.45.0.518114072349.issue12062@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed now. Again, thank you reporting this bug!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12062>
_______________________________________

From report at bugs.python.org  Fri May 13 00:34:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 22:34:35 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305237119.97.0.720079360847.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305239640.10158.13.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It's not the only shortage with the current implementation regarding
> (real-time) signals. Another one is that they're delivered
> out-of-order (lowest-numbered signal first),

Oh yes, it can be a problem.

> and the most important one - especially for real-time signals - is
> that the handlers are executed synchronously, when Py_CheckSignals()
> is called.

Evaluate Python code in a signal handler is really not a good idea! And
because of the GIL, I don't think that we can do better. But with the
GIL of Python 3.3, the Python signal handler will be called "immediatly"
before the next instruction, instead of having to wait something like
100 Python instructions (sys.getcheckinterval()). On this point, Python
3.3 is better than all previous versions.

> While we can't do much about the the later, there's at least a way to
> handle the other issues, a small variant of the self-pipe trick:
> (...)
> drawbacks:
> - might be a bit slower, because of the read syscall
> - consumes 2 FDs

Consume 2 FDs can be surprising. We cannot do that by default (just to
have in-order or real time signals).

> - have to reinit the pipe on fork

Oh yes, it can be a problem.

> - does Windows have pipe/read/write?

Do you really think that Windows supports real time signals? :) Windows
has pipes: see the Connection object of the multiprocessing module
(Antoine is working on this topic). But I don't remember if they can be
used as POSIX files (using file descriptors).

> - maybe overkill
>
> But I'm really not sure that fixing this is worth it...

It looks like your reimplements the whole signal machinery between the
kernel and the application... But anyway, we need something between the
C signal handler and the Python signal handler (because we cannot
execute Python code in a C signal handler).

Well, we can imagine to have an option/function to enable real time
and/or in-order signals (e.g. using pipes).

Can we call this mode "real time"? Real time means that we warranty a
maximum response time.

> By the way, to be pedantic, in the current code, wakeup_fd and
> Handlers should be volatile, and tripped should be sig_atomic_t.

Yes. Can you please write a patch for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Fri May 13 00:35:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 22:35:36 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305239736.16.0.136374007773.issue5723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

With this approach is necessary to exclude the base class from the tests, either by listing all the Python/C tests explicitly or doing some automatic check to find these base classes.  Listing all the tests is a bad idea because it needs to be updated manually and it's easy to forget about that and end up with tests that are never run.  Checking and skipping the base classes is not very elegant IMHO.

It also requires an extra base class, and even if it's more flexible because it makes possible to add Python-specific tests easily, that's not necessary with json because all the tests run unchanged on both pyjson and cjson.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Fri May 13 00:47:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2011 22:47:46 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1305239736.16.0.136374007773.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305240462.3548.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> With this approach is necessary to exclude the base class from the
> tests, either by listing all the Python/C tests explicitly or doing
> some automatic check to find these base classes.

It just needs a small change then:

class PyTest(TestCase):
    ...
class CTest(TestCase):
    ...

class TestSomething:
    def test_something(self): ...

class TestPySomething(TestSomething, PyTest): pass
class TestCSomething(TestSomething, CTest): pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Fri May 13 01:02:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2011 23:02:47 +0000
Subject: [issue12069] test_signal.test_without_siginterrupt() failure on AMD64
	OpenIndiana 3.x
In-Reply-To: <1305241367.49.0.983669109712.issue12069@psf.upfronthosting.co.za>
Message-ID: <1305241367.49.0.983669109712.issue12069@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_signal fails sometimes on the "AMD64 OpenIndiana 3.x" buildbot:

Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_signal.py", line 358, in test_without_siginterrupt
    self.assertTrue(i)
AssertionError: False is not true

http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1188/steps/test/logs/stdio

This failure may be related to my recent work on signals, see #8407.

----------
messages: 135882
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_signal.test_without_siginterrupt() failure on AMD64 OpenIndiana 3.x
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12069>
_______________________________________

From report at bugs.python.org  Fri May 13 01:23:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2011 23:23:52 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305242632.38.0.0873269774002.issue5723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My usual pattern (adopted from examples in the stdlib tests) is this:

TestSomethingBase:

    tests

PyTestSomething(TestSomethingBase, TestCase):
    stuff

CTestSomething(TestSomethingBase, TestCase):
    stuff

Is there a reason that won't work in your case?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Fri May 13 01:32:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 May 2011 23:32:43 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305243163.41.0.786038174275.issue5723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Technically they both work, they are just two different approaches that offer more or less the same compromise between features and verbosity.
Your approach requires an extra class for each test but saves you from setting the module attribute and the skip, mine is the other way around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Fri May 13 01:59:39 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 12 May 2011 23:59:39 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305239640.10158.13.camel@marge>
Message-ID: <BANLkTimpJOjWYMbKwEhx+WedghUUT+r5dg@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> Evaluate Python code in a signal handler is really not a good idea!

I know, you're limited to async-safe functions, among other things :-)

> because of the GIL, I don't think that we can do better. But with the
> GIL of Python 3.3, the Python signal handler will be called "immediatly"
> before the next instruction, instead of having to wait something like
> 100 Python instructions (sys.getcheckinterval()). On this point, Python
> 3.3 is better than all previous versions.
>

Nice.

> Well, we can imagine to have an option/function to enable real time
> and/or in-order signals (e.g. using pipes).
>
> Can we call this mode "real time"? Real time means that we warranty a
> maximum response time.
>

Well, I think that we should either make this the default behaviour
(that's why I was asking whether it's possible on Windows), or not
implement it. Having two modes for signal handling is confusing.
But given that this behaviour has never been noticed before and that I
doubt that people needing real-time signals use Python (and
vice-versa), maybe we should just stick with the current
implementation, which is safe and simple (see Antoine's question, "Is
it a theoretical concern or does it affect real software?").
On the other hand, if it turns out to be interesting to some people,
I'd be happy to work on a patch.

>> By the way, to be pedantic, in the current code, wakeup_fd and
>> Handlers should be volatile, and tripped should be sig_atomic_t.
>
> Yes. Can you please write a patch for this?

Patch attached.

----------
Added file: http://bugs.python.org/file21989/signal_pedantic.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________
-------------- next part --------------
diff -r 3ebe2d261920 Modules/signalmodule.c
--- a/Modules/signalmodule.c	Thu May 12 16:18:29 2011 +0100
+++ b/Modules/signalmodule.c	Fri May 13 01:11:27 2011 +0200
@@ -88,12 +88,12 @@
 static pid_t main_pid;
 #endif
 
-static struct {
-    int tripped;
+static volatile struct {
+    sig_atomic_t tripped;
     PyObject *func;
 } Handlers[NSIG];
 
-static sig_atomic_t wakeup_fd = -1;
+static volatile sig_atomic_t wakeup_fd = -1;
 
 /* Speed up sigcheck() when none tripped */
 static volatile sig_atomic_t is_tripped = 0;

From report at bugs.python.org  Fri May 13 03:08:00 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 13 May 2011 01:08:00 +0000
Subject: [issue12069] test_signal.test_without_siginterrupt() failure on AMD64
	OpenIndiana 3.x
In-Reply-To: <1305241367.49.0.983669109712.issue12069@psf.upfronthosting.co.za>
Message-ID: <1305248880.76.0.0233151795414.issue12069@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/issue12069>
_______________________________________

From report at bugs.python.org  Fri May 13 03:19:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2011 01:19:03 +0000
Subject: [issue11896] Save on Close fails in IDLE, from Linux system
In-Reply-To: <1303365966.87.0.683808502897.issue11896@psf.upfronthosting.co.za>
Message-ID: <E1QKh1x-00011x-EY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ac14158462cf by Kurt B. Kaiser in branch '2.7':
Issue #11896: Save on Close failed despite selecting "Yes" in dialog.
http://hg.python.org/cpython/rev/ac14158462cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11896>
_______________________________________

From report at bugs.python.org  Fri May 13 05:42:58 2011
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 13 May 2011 03:42:58 +0000
Subject: [issue5559] IDLE Output Window 's goto fails when path has spaces
In-Reply-To: <1237951372.91.0.474657570766.issue5559@psf.upfronthosting.co.za>
Message-ID: <1305258178.25.0.535056714995.issue5559@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Backported to 2.6 4Oct09  56387:490190cb4a57

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5559>
_______________________________________

From report at bugs.python.org  Fri May 13 06:37:18 2011
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 13 May 2011 04:37:18 +0000
Subject: [issue7738] IDLE hang when tooltip comes up in Linux
In-Reply-To: <1263889833.11.0.812168606755.issue7738@psf.upfronthosting.co.za>
Message-ID: <1305261438.07.0.406051372565.issue7738@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Linux trader 2.6.38-2-686 #1 SMP Thu Apr 7 05:24:21 UTC 2011 i686 GNU/Linux
kbk at trader:~/Python/Py27$ aptitude show tk8.5
Package: tk8.5
...
Version: 8.5.9-2

Debian Linux Wheezy

Can't reproduce on 2.7.1+ 3.1.4+ 3.2.1beta 3.3alpha0 with Tk8.4 Tk8.5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7738>
_______________________________________

From report at bugs.python.org  Fri May 13 07:39:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 May 2011 05:39:56 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305265196.74.0.0337646932565.issue5723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch uses the approach described in msg135881.

----------
Added file: http://bugs.python.org/file21990/issue5723-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Fri May 13 09:20:43 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 13 May 2011 07:20:43 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1305271243.86.0.874496378001.issue12067@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Docs]
"If both are numbers, they are converted to a common type."

[Terry]
"In any case, I think it is only true for built-in number types,"

It's not even true for built-in number types.  When comparing an int with a float, it's definitely *not* the case that the int is converted to a float and the floats compared.  And that's for good reason:  the int -> float conversion is lossy for large integers, so if int <-> float comparisons just converted the int to a float before comparing, we'd have (for example):

>>> 10**16 == 1e16 == 10**16 + 1

leading to broken transitivity of equality, and strange dict and set behaviour.

So int <-> float comparisons do a complicated dance under the hood to compare the exact numerical values of the two objects and produce the correct result.

I'm not sure what the intent of the original sentence was, or how to reword it.  The key point is simply that it *is* possible to compare an int with a float, and that the result is sensible, based on numeric values.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12067>
_______________________________________

From report at bugs.python.org  Fri May 13 09:31:31 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 13 May 2011 07:31:31 +0000
Subject: [issue12064] unexpected behavior with exception variable
In-Reply-To: <1305222776.86.0.399982942497.issue12064@psf.upfronthosting.co.za>
Message-ID: <1305271891.82.0.962920175727.issue12064@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
superseder:  -> except-as in Py3 eats variables

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12064>
_______________________________________

From report at bugs.python.org  Fri May 13 10:02:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 May 2011 08:02:24 +0000
Subject: [issue12066] Empty ('') xmlns attribute is not properly handled by
	xml.dom.minidom
In-Reply-To: <1305234676.35.0.0571872848833.issue12066@psf.upfronthosting.co.za>
Message-ID: <1305273744.86.0.716652135662.issue12066@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/issue12066>
_______________________________________

From report at bugs.python.org  Fri May 13 10:03:56 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 13 May 2011 08:03:56 +0000
Subject: [issue12046] Windows build identification incomplete
In-Reply-To: <1304982255.24.0.451713108617.issue12046@psf.upfronthosting.co.za>
Message-ID: <1305273836.16.0.208373801268.issue12046@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd rather not patch the build process manually during a release, so probably there just won't be a hg build identification in the Windows binaries, then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12046>
_______________________________________

From report at bugs.python.org  Fri May 13 12:21:13 2011
From: report at bugs.python.org (Ralf Schlatterbeck)
Date: Fri, 13 May 2011 10:21:13 +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: <1305282073.12.0.764926242637.issue10945@psf.upfronthosting.co.za>


Ralf Schlatterbeck <rsc at runtux.com> added the comment:

I've just been bitten by this when trying to do a new release of roundup, why not make the mbcs codec available on non-windows platforms as has been proposed (and rejected) in issue1251921 -- any non-technical reasons for not including this codec on other platforms?

----------
nosy: +runtux

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Fri May 13 12:29:16 2011
From: report at bugs.python.org (Ralf Schlatterbeck)
Date: Fri, 13 May 2011 10:29:16 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1305282556.46.0.906373959442.issue8954@psf.upfronthosting.co.za>


Ralf Schlatterbeck <rsc at runtux.com> added the comment:

2.6 already produces a .linux-i686.exe package instead of .win32.exe when running bdist_wininst. I've now used python2.5 for producing a binary windows installer for roundup.

----------
nosy: +runtux
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Fri May 13 12:31:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 13 May 2011 10:31:02 +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: <1305282662.14.0.239831457831.issue10945@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The mbcs codec depends on the Windows installation. On most Western Windows it is similar to cp1252, Japanese Windows will use cp932, and so on.
If we were to provide mbcs on non-windows platform, it should be an alias to ascii.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10945>
_______________________________________

From report at bugs.python.org  Fri May 13 12:40:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 May 2011 10:40:04 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1305283204.11.0.0887437824261.issue9205@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Antoine, I've got a couple questions concerning your patch:
- IIUC, the principle is to create a pipe for each worker process, so that when the child exits the read-end - sentinel - becomes readable (EOF) from the parent, so you know that a child exited. Then, before reading from the the result queue, you perform a select on the list of sentinels to check that all workers are alive. Am I correct?
If I am, then I have the following questions:
- have you done some benchmarking to measure the performance impact of calling select at every get (I'm not saying it will necessary be noticeable, I'm just curious)?
- isn't there a race if a process exits between the time select returns and the get?
- is there a distinction between a normal exit and an abnormal one? The reason I'm asking is because with multiprocessing.Pool, you can have a maxtasksperchild argument which will make workers exit after having processed a given number of tasks, so I'm wondering how that would be handled with the current patch (on the other side, I think you patch only applies to concurrent.futures, not to raw Queues, right?).

Finally, I might be missing something completely obvious, but I have the feeling that POSIX already provides something that could help solve this issue: process groups.
We could create a new process group for a process pool, and checking whether children are still alive would be as simple as waitpid(-group, os.WNOHANG) (I don't know anything about Windows, but Google returned WaitForMultipleObjects which seems to work on multiple processes). You'd get the exit code for free.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Fri May 13 12:57:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 May 2011 10:57:55 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1305283204.11.0.0887437824261.issue9205@psf.upfronthosting.co.za>
Message-ID: <1305284268.3561.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, I've got a couple questions concerning your patch:
> - IIUC, the principle is to create a pipe for each worker process, so
> that when the child exits the read-end - sentinel - becomes readable
> (EOF) from the parent, so you know that a child exited. Then, before
> reading from the the result queue, you perform a select on the list of
> sentinels to check that all workers are alive. Am I correct?

Not exactly. The select is done on the queue's pipe and on the workers'
fds *at the same time*. Thus there's no race condition.

> - have you done some benchmarking to measure the performance impact of
> calling select at every get (I'm not saying it will necessary be
> noticeable, I'm just curious)?

No, but the implementation is not meant to be blazingly fast anyway
(after all, it has just been rewritten in Python from C).

> - is there a distinction between a normal exit and an abnormal one?

Not at that level. In concurrent.futures, a process exiting normally
first sends its pid on the result queue. The parent then dequeues the
pid and knows the process has ended cleanly.

This approach could work for multiprocessing.Pool as well. However, the
patch only caters with concurrent.futures indeed. 

> Finally, I might be missing something completely obvious, but I have
> the feeling that POSIX already provides something that could help
> solve this issue: process groups.
> We could create a new process group for a process pool, and checking
> whether children are still alive would be as simple as waitpid(-group,
> os.WNOHANG)

waitpid() doesn't allow for a timeout, and it doesn't allow to check a
pipe concurrently, does it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Fri May 13 13:15:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 May 2011 11:15:03 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1305230511.18.0.0895360934602.issue6721@psf.upfronthosting.co.za>
Message-ID: <1305285300.3561.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> ...so how can we establish correct (cross library) locking order
> during prepare stage?

That sounds like a lost battle, if it requires the libraries'
cooperation. I think resetting locks is the best we can do. It might not
work ok in all cases, but if it can handle simple cases (such as I/O and
logging locks), it is already very good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri May 13 13:16:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2011 11:16:12 +0000
Subject: [issue12068] test_logging failure in test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <E1QKqLq-00026S-GQ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 660a4a6dc2cd by Vinay Sajip in branch 'default':
Issue #12068: Fix appears to have worked; added more diagnostics for rare failures.
http://hg.python.org/cpython/rev/660a4a6dc2cd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12068>
_______________________________________

From report at bugs.python.org  Fri May 13 13:24:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 May 2011 11:24:35 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1305230511.18.0.0895360934602.issue6721@psf.upfronthosting.co.za>
Message-ID: <BANLkTinXqo5D6vm51AVoPEwneRVPoxmfKw@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> Hi,
>

Hello Nir,

> Option (2) makes sense but is probably not always applicable.
> Option (1) depends on being able to acquire locks in locking order, but how
> can we determine correct locking order across libraries?
>

There are indeed a couple problems with 1:
1) actually, releasing the mutex/semaphore from the child is not
guaranteed to be safe, see this comment from glibc's malloc:
/* In NPTL, unlocking a mutex in the child process after a
   fork() is currently unsafe, whereas re-initializing it is safe and
   does not leak resources.  Therefore, a special atfork handler is
   installed for the child. */
We could just destroy/reinit them, though.

2) acquiring locks just before fork is probably one of the best way to
deadlock (acquiring a lock we already hold, or acquiring a lock needed
by another thread before it releases its own lock). Apart from adding
dealock avoidance/recovery mechanisms - which would be far from
trivial - I don't see how we could solve this, given that each library
can use its own locks, not counting the user-created ones

3) there's another special lock we must take into account, the GIL:
contrarily to a typical C program, we can't have the thread forking
blindly try to acquire all locks just before fork, because since we
hold the GIL, other threads won't be able to proceed (unless of course
they're in a section where they don't run without the GIL held).

So, we would have to:
- release the GIL
- acquire all locks in the correct order
- re-acquire the GIL
- fork
- reinit all locks after fork

I think this is going to be very complicated.

4) Python locks differ from usual mutexes/semaphores in that they can
be held for quite some time (for example while performing I/O). Thus,
acquiring all the locks could take a long time, and users might get
irritated if fork takes 2 seconds to complete.

5) Finally, there's a fundamental problem with this approach, because
Python locks can be released by a thread other than the one that owns
it.
Imagine this happens:

T1                         T2
                          lock.acquire()
                          (do something without releasing lock)
fork()
lock.release()

This is perfectly valid with the current lock implementation (for
example, it can be used to implement a rendez-vous point so that T2
doesn't start processing before T1 forked worker processes, or
whatever).
But if T1 tries to acquire lock (held by T2) before fork, then it will
deadlock, since it will never be release by T2.

For all those reasons, I don't think that this approach is reasonable,
but I could be wrong :-)

> Initializing locks in child after fork without acquiring them before the
> fork may result in corrupted program state and so is probably not a good
> idea.

Yes, but in practise, I think that this shouldn't be too much of a
problem. Also note that you can very well have the same type of
problem with sections not protected explicitely by locks: for example,
if you have a thread working exclusively on an object (maybe part of a
threadpool), a fork can very well happen while the object is in an
inconsistent state. Acquiring locks before fork won't help that.
But I think this should eventually be addressed, maybe by specific
atfork handlers.

> On a positive note, if I understand correctly, Python signal handler
> functions are actually run in the regular interpreter loop (as pending
> calls) after the signal has been handled and so os.fork() atfork handlers
> will not be restricted to async-signal-safe operations (since a Python fork
> is never done in a signal handler).

That's correct.

In short, I think that we could first try to avoid common deadlocks by
just resetting locks in the child process. This is not panacea, but
this should solve the vast majority of deadlocks, and would open the
door to potential future refinements using atfork-like handlers.

Attached is a first draft for a such patch (with tests).
Synopsis:
- when a PyThread_type_lock is created, it's added to a linked-list,
when it's deleted, it's removed from the linked list
- PyOS_AfterFork() calls PyThread_ReinitLocks() which calls
PyThread_reinit_lock() for each lock in the linked list
- PyThread_reinit_lock() does the right thing (i.e. sem_destroy/init
for USE_SEMAPHORES and pthread_(mutex|cond)_destroy/init for emulated
semaphores).

Notes:
- since it's only applicable to POSIX (since other Unix thread
implementations will be dropped), I've only defined a
PyThread_ReinitLocks inside Python/thread_pthread.h, so it won't build
on other platforms. How should I proceed: like PyThread_ReInitTLS(),
add a stub function to all Python/thread_xxx.h, or guard the call to
PyThread_ReinitLocks() with #ifdef _POSIX_THREADS ?
- I'm not sure of how to handle sem_init/etc failures in the reinit
code: for now I just ignore this possibility, like what's done for the
import lock reset
- insertions/removals from the linked list are not protected from
concurrent access because I assume that locks are created/deleted with
the GIL held: is that a reasonable assumption, or should I add a mutex
to protect those accesses?

This fixes common deadlocks with threading.Lock, and
PyThread_type_lock (used for example by I/O code).

----------
Added file: http://bugs.python.org/file21991/reinit_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________
-------------- next part --------------
diff -r 3ebe2d261920 Include/pythread.h
--- a/Include/pythread.h	Thu May 12 16:18:29 2011 +0100
+++ b/Include/pythread.h	Thu May 12 22:28:38 2011 +0200
@@ -84,6 +84,7 @@
 PyAPI_FUNC(void) PyThread_delete_key_value(int key);
 
 /* Cleanup after a fork */
+PyAPI_FUNC(void) PyThread_ReInitLocks(void);
 PyAPI_FUNC(void) PyThread_ReInitTLS(void);
 
 #ifdef __cplusplus
diff -r 3ebe2d261920 Lib/test/lock_tests.py
--- a/Lib/test/lock_tests.py	Thu May 12 16:18:29 2011 +0100
+++ b/Lib/test/lock_tests.py	Thu May 12 22:28:38 2011 +0200
@@ -3,6 +3,7 @@
 """
 
 import sys
+import os
 import time
 from _thread import start_new_thread, get_ident, TIMEOUT_MAX
 import threading
@@ -286,6 +287,66 @@
         self.assertFalse(lock._is_owned())
 
 
+class LockAfterForkTests(BaseTestCase):
+    """
+    Tests that standard and internal locks (e.g. I/O) are correctly
+    re-initialized after fork.
+    """
+
+    def test_lock_after_fork(self):
+        lock = self.locktype()
+        lock.acquire()
+        pid = os.fork()
+        if pid == 0:
+            # the lock should be re-initialized
+            for i in range(5):
+                lock.acquire()
+                lock.release()
+            os._exit(0)
+        else:
+            lock.release()
+            os.waitpid(pid, 0)
+
+    def test_lock_after_fork_from_thread(self):
+        # same thing, but with a lock acquired from another thread
+        lock = self.locktype()
+        def f():
+            lock.acquire()
+        b = Bunch(f, 1)
+        b.wait_for_finished()
+        pid = os.fork()
+        if pid == 0:
+            # the lock should be re-initialized
+            lock.acquire()
+            lock.release()
+            os._exit(0)
+        else:
+            lock.release()
+            os.waitpid(pid, 0)
+
+    def test_iolock_after_fork(self):
+        r, w = os.pipe()
+        rf = os.fdopen(r)
+        def f():
+            # this will block with the file's lock held
+            rf.read(1)
+        b = Bunch(f, 1)
+        time.sleep(0.1)
+        # fork while the file's lock is held, and close the write-end so that
+        # the thread and child process receive EOF
+        pid = os.fork()
+        os.close(w)
+        if pid == 0:
+            # the file's lock should be reinitialized, should get EOF
+            rf.read(1)
+            rf.close()
+            os._exit(0)
+        else:
+            b.wait_for_finished()
+            rf.close()
+            os.waitpid(pid, 0)
+
+
 class EventTests(BaseTestCase):
     """
     Tests for Event objects.
diff -r 3ebe2d261920 Lib/test/test_threading.py
--- a/Lib/test/test_threading.py	Thu May 12 16:18:29 2011 +0100
+++ b/Lib/test/test_threading.py	Thu May 12 22:28:38 2011 +0200
@@ -713,6 +713,10 @@
 class CRLockTests(lock_tests.RLockTests):
     locktype = staticmethod(threading._CRLock)
 
+ at unittest.skipUnless(hasattr(os, 'fork'), "needs os.fork()")
+class LockAfterForkTests(lock_tests.LockAfterForkTests):
+    locktype = staticmethod(threading.Lock)
+
 class EventTests(lock_tests.EventTests):
     eventtype = staticmethod(threading.Event)
 
@@ -734,7 +738,8 @@
 
 
 def test_main():
-    test.support.run_unittest(LockTests, PyRLockTests, CRLockTests, EventTests,
+    test.support.run_unittest(LockTests, PyRLockTests, CRLockTests,
+                              LockAfterForkTests, EventTests,
                               ConditionAsRLockTests, ConditionTests,
                               SemaphoreTests, BoundedSemaphoreTests,
                               ThreadTests,
diff -r 3ebe2d261920 Modules/_threadmodule.c
--- a/Modules/_threadmodule.c	Thu May 12 16:18:29 2011 +0100
+++ b/Modules/_threadmodule.c	Thu May 12 22:28:38 2011 +0200
@@ -322,7 +322,10 @@
         r = acquire_timed(self->rlock_lock, microseconds);
     }
     if (r == PY_LOCK_ACQUIRED) {
-        assert(self->rlock_count == 0);
+        if (self->rlock_count != 0) {
+            PyErr_SetString(ThreadError, "couldn't acquire lock");
+            return NULL;
+        }
         self->rlock_owner = tid;
         self->rlock_count = 1;
     }
@@ -393,11 +396,10 @@
         r = PyThread_acquire_lock(self->rlock_lock, 1);
         Py_END_ALLOW_THREADS
     }
-    if (!r) {
+    if (!r || self->rlock_count != 0) {
         PyErr_SetString(ThreadError, "couldn't acquire lock");
         return NULL;
     }
-    assert(self->rlock_count == 0);
     self->rlock_owner = owner;
     self->rlock_count = count;
     Py_RETURN_NONE;
diff -r 3ebe2d261920 Modules/signalmodule.c
--- a/Modules/signalmodule.c	Thu May 12 16:18:29 2011 +0100
+++ b/Modules/signalmodule.c	Thu May 12 22:28:38 2011 +0200
@@ -1234,6 +1234,7 @@
 PyOS_AfterFork(void)
 {
 #ifdef WITH_THREAD
+    PyThread_ReinitLocks();
     _PyGILState_Reinit();
     PyEval_ReInitThreads();
     main_thread = PyThread_get_thread_ident();
diff -r 3ebe2d261920 Python/thread_pthread.h
--- a/Python/thread_pthread.h	Thu May 12 16:18:29 2011 +0100
+++ b/Python/thread_pthread.h	Thu May 12 22:28:38 2011 +0200
@@ -104,6 +104,16 @@
 } while(0)
 
 
+/* pthread lock definition */
+#ifdef USE_SEMAPHORES
+
+typedef struct _pthread_lock {
+    sem_t sem;
+    struct _pthread_lock *next;
+} pthread_lock;
+
+#else
+
 /* A pthread mutex isn't sufficient to model the Python lock type
  * because, according to Draft 5 of the docs (P1003.4a/D5), both of the
  * following are undefined:
@@ -119,15 +129,47 @@
  * bit is cleared.     9 May 1994 tim at ksr.com
  */
 
-typedef struct {
+typedef struct _pthread_lock {
     char             locked; /* 0=unlocked, 1=locked */
     /* a <cond, mutex> pair to handle an acquire of a locked lock */
     pthread_cond_t   lock_released;
     pthread_mutex_t  mut;
+    struct _pthread_lock *next;
 } pthread_lock;
 
+#endif /* USE_SEMAPHORES */
+
 #define CHECK_STATUS(name)  if (status != 0) { perror(name); error = 1; }
 
+
+/* head of the linked list of locks */
+static pthread_lock *locks_head = NULL;
+
+
+/* linked list handling routines */
+Py_LOCAL_INLINE(void)
+list_add(pthread_lock **head, pthread_lock *e)
+{
+    e->next = *head;
+    *head = e;
+}
+
+Py_LOCAL_INLINE(void)
+list_remove(pthread_lock **head, pthread_lock *e)
+{
+    if (*head == e) {
+        *head = e->next;
+    } else {
+        pthread_lock *cur;
+        for (cur = *head; cur != NULL; cur = cur->next) {
+            if (cur->next == e) {
+                cur->next = e->next;
+                break;
+            }
+        }
+    }
+}
+
 /*
  * Initialization.
  */
@@ -258,22 +300,24 @@
 PyThread_type_lock
 PyThread_allocate_lock(void)
 {
-    sem_t *lock;
+    pthread_lock *lock;
     int status, error = 0;
 
     dprintf(("PyThread_allocate_lock called\n"));
     if (!initialized)
         PyThread_init_thread();
 
-    lock = (sem_t *)malloc(sizeof(sem_t));
+    lock = malloc(sizeof(pthread_lock));
 
     if (lock) {
-        status = sem_init(lock,0,1);
+        status = sem_init(&lock->sem,0,1);
         CHECK_STATUS("sem_init");
 
         if (error) {
             free((void *)lock);
             lock = NULL;
+        } else {
+            list_add(&locks_head, lock);
         }
     }
 
@@ -284,7 +328,7 @@
 void
 PyThread_free_lock(PyThread_type_lock lock)
 {
-    sem_t *thelock = (sem_t *)lock;
+    pthread_lock *thelock = (pthread_lock *)lock;
     int status, error = 0;
 
     dprintf(("PyThread_free_lock(%p) called\n", lock));
@@ -292,12 +336,27 @@
     if (!thelock)
         return;
 
-    status = sem_destroy(thelock);
+    list_remove(&locks_head, thelock);
+
+    status = sem_destroy(&thelock->sem);
     CHECK_STATUS("sem_destroy");
 
     free((void *)thelock);
 }
 
+void
+PyThread_reinit_lock(PyThread_type_lock lock)
+{
+    pthread_lock *thelock = (pthread_lock *)lock;
+
+    dprintf(("PyThread_reinit_lock(%p) called\n", lock));
+
+    (void)sem_destroy(&thelock->sem);
+
+    (void)sem_init(&thelock->sem, 0, 1);
+}
+
+
 /*
  * As of February 2002, Cygwin thread implementations mistakenly report error
  * codes in the return value of the sem_ calls (like the pthread_ functions).
@@ -315,7 +374,7 @@
                             int intr_flag)
 {
     PyLockStatus success;
-    sem_t *thelock = (sem_t *)lock;
+    pthread_lock *thelock = (pthread_lock *)lock;
     int status, error = 0;
     struct timespec ts;
 
@@ -326,11 +385,11 @@
         MICROSECONDS_TO_TIMESPEC(microseconds, ts);
     do {
         if (microseconds > 0)
-            status = fix_status(sem_timedwait(thelock, &ts));
+            status = fix_status(sem_timedwait(&thelock->sem, &ts));
         else if (microseconds == 0)
-            status = fix_status(sem_trywait(thelock));
+            status = fix_status(sem_trywait(&thelock->sem));
         else
-            status = fix_status(sem_wait(thelock));
+            status = fix_status(sem_wait(&thelock->sem));
         /* Retry if interrupted by a signal, unless the caller wants to be
            notified.  */
     } while (!intr_flag && status == EINTR);
@@ -366,12 +425,12 @@
 void
 PyThread_release_lock(PyThread_type_lock lock)
 {
-    sem_t *thelock = (sem_t *)lock;
+    pthread_lock *thelock = (pthread_lock *)lock;
     int status, error = 0;
 
     dprintf(("PyThread_release_lock(%p) called\n", lock));
 
-    status = sem_post(thelock);
+    status = sem_post(&thelock->sem);
     CHECK_STATUS("sem_post");
 }
 
@@ -412,6 +471,8 @@
         if (error) {
             free((void *)lock);
             lock = 0;
+        } else {
+            list_add(&locks_head, lock);
         }
     }
 
@@ -427,6 +488,8 @@
 
     dprintf(("PyThread_free_lock(%p) called\n", lock));
 
+    list_remove(&locks_head, thelock);
+
     status = pthread_mutex_destroy( &thelock->mut );
     CHECK_STATUS("pthread_mutex_destroy");
 
@@ -436,6 +499,22 @@
     free((void *)thelock);
 }
 
+void
+PyThread_reinit_lock(PyThread_type_lock lock)
+{
+    pthread_lock *thelock = (pthread_lock *)lock;
+
+    dprintf(("PyThread_reinit_lock(%p) called\n", lock));
+
+    (void)pthread_mutex_destroy(&thelock->mut);
+    (void)pthread_cond_destroy(&thelock->lock_released);
+
+    thelock->locked = 0;
+    (void)pthread_mutex_init(&thelock->mut, pthread_mutexattr_default);
+    _Py_ANNOTATE_PURE_HAPPENS_BEFORE_MUTEX(&thelock->mut);
+    (void)pthread_cond_init(&thelock->lock_released, pthread_condattr_default);
+}
+
 PyLockStatus
 PyThread_acquire_lock_timed(PyThread_type_lock lock, PY_TIMEOUT_T microseconds,
                             int intr_flag)
@@ -525,6 +604,37 @@
 
 #endif /* USE_SEMAPHORES */
 
+/*
+ * After fork, POSIX explicitly states that locks and other synchronization
+ * primitives are unusable in the child process. This can trigger random
+ * deadlocks and even segfaults in rare cases.
+ * To mitigate this issue, PyThread_ReinitLocks is called by PyOS_AfterFork and
+ * re-initializes locks so that they are usable in the child process.
+ * Notes:
+ *  - This only applies to raw locks, i.e. locks allocated directly through
+ *    PyThread_allocate_lock, such as threading.Lock and locks used in C code
+ *    (e.g. I/O code). This doesn't solve the problem for RLock and
+ *    higher-level synchronization primitives such as Condition and Event
+ *    (those could probably be handled by a pthread_atfork-like mechanism
+ *    invoked by PyOS_AfterFork).
+ *  - Calling pthread_mutex_destroy/sem_destroy from the child process should
+ *    be safe and avoid leaks. If it turns out to cause problems with some
+ *    pthread implementations, those could probably be removed, calling just
+ *    pthread_mutex_init/sem_init.
+ *  - The linked list of locks (locks_head) doesn't need to be protected from
+ *    concurrent access because locks are created/destroyed with the GIL held,
+ *    and PyThread_ReinitLocks is called after fork, so there's only one
+ *    running thread at that point.
+*/
+void
+PyThread_ReinitLocks(void)
+{
+    pthread_lock *l;
+
+    for (l = locks_head; l != NULL; l = l->next)
+        PyThread_reinit_lock(l);
+}
+
 int
 PyThread_acquire_lock(PyThread_type_lock lock, int waitflag)
 {

From report at bugs.python.org  Fri May 13 14:03:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 12:03:08 +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: <1305288188.71.0.588329402583.issue12013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Is the original bug still present in your new install?
I meant your server.  I?d like to know whether this is a legit but or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Fri May 13 14:37:30 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 13 May 2011 12:37:30 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305290250.61.0.491727745077.issue3871@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 13 15:05:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 May 2011 13:05:19 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1305284268.3561.7.camel@localhost.localdomain>
Message-ID: <BANLkTikFRc7d=Cs0Q5-623e=iiTE_R9o3A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Not exactly. The select is done on the queue's pipe and on the workers'
> fds *at the same time*. Thus there's no race condition.

You're right, I missed this part, it's perfectly safe.

But I think there's a problem with the new implementation in Python.
Writes to a pipe are guaranteed to be atomic if you write less than
PIPE_BUF (4K on Linux, 512 by POSIX) at a time. Writes to a datagram
Unix domain socket are also atomic.
But Lib/multiprocessing/connection.py does:

    def _send_bytes(self, buf):
        # For wire compatibility with 3.2 and lower
        n = len(buf)
        self._send(struct.pack("=i", len(buf)))
        # The condition is necessary to avoid "broken pipe" errors
        # when sending a 0-length buffer if the other end closed the pipe.
        if n > 0:
            self._send(buf)

This is definitely not atomic. If two processes write objects of
different size at the same time, it can probably lead to trouble.
Also, Pipe(duplex=True) should probably return a SOCK_DGRAM Unix
socket for the same reason.
If I missed something here, I promise to shut up ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Fri May 13 15:09:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 13:09:24 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1305292164.13.0.212070813049.issue8954@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

2.6 only gets security fixes.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Fri May 13 15:11:58 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Fri, 13 May 2011 13:11:58 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1305068684.08.0.750782613492.issue6011@psf.upfronthosting.co.za>
Message-ID: <4DCD2DD2.1020503@free.fr>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

Indeed, I retried with 534a9e274d88 (that was the tip of 3.2 sometime 
yesterday) and my original problem is solved. Thank you.

While I was at it, I ran "make test",  and got 3 unusual skips and 1 
failure.

The skips are test_sax, test_xml_etree and test_xml_etree_c and they are 
skipped on purpose when the example XML filename is not encodable to 
utf8. No problem here.

The failure is for test_distutils. 3 individual tests are failing: 
test_simple_built, test_debug_mode and test_record. The cause of this 
failure is that the "install" command installs a test distribution to a 
path containing sys.prefix. This is not a problem per se, but later 
test_simple_built tries to zip this distribution, and cannot construct a 
valid archive name. A similar problem happens when test_record tries to 
write the distribution's filenames to a record file (and test_debug_mode 
fails because of test_record).

Imho those failures cannot be fixed, so the only possible improvement is 
to skip those tests. The attached trivial patch does just that, but I'm 
not sure if it's worth patching distutils for that.

Cheers,
Baptiste

----------
Added file: http://bugs.python.org/file21992/test_distutils_surrogateescape.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________
-------------- next part --------------
diff --git a/Lib/distutils/tests/test_bdist_dumb.py b/Lib/distutils/tests/test_bdist_dumb.py
--- a/Lib/distutils/tests/test_bdist_dumb.py
+++ b/Lib/distutils/tests/test_bdist_dumb.py
@@ -24,6 +24,12 @@
 except ImportError:
     ZLIB_SUPPORT = False
 
+try:
+    os.path.normpath(sys.prefix).encode("utf8")
+    PREFIX_NOT_UTF8 = False
+except UnicodeEncodeError:
+    PREFIX_NOT_UTF8 = True
+
 
 class BuildDumbTestCase(support.TempdirManager,
                         support.LoggingSilencer,
@@ -42,6 +48,7 @@
         super(BuildDumbTestCase, self).tearDown()
 
     @unittest.skipUnless(ZLIB_SUPPORT, 'Need zlib support to run')
+    @unittest.skipIf(PREFIX_NOT_UTF8, 'prefix is not encodable to utf8')
     def test_simple_built(self):
 
         # let's create a simple package
diff --git a/Lib/distutils/tests/test_install.py b/Lib/distutils/tests/test_install.py
--- a/Lib/distutils/tests/test_install.py
+++ b/Lib/distutils/tests/test_install.py
@@ -16,6 +16,13 @@
 
 from distutils.tests import support
 
+try:
+    os.path.normpath(sys.prefix).encode("utf8")
+    PREFIX_NOT_UTF8 = False
+except UnicodeEncodeError:
+    PREFIX_NOT_UTF8 = True
+
+
 class InstallTestCase(support.TempdirManager,
                       support.EnvironGuard,
                       support.LoggingSilencer,
@@ -166,6 +173,7 @@
         cmd.user = 'user'
         self.assertRaises(DistutilsOptionError, cmd.finalize_options)
 
+    @unittest.skipIf(PREFIX_NOT_UTF8, 'prefix is not encodable to utf8')
     def test_record(self):
 
         install_dir = self.mkdtemp()

From report at bugs.python.org  Fri May 13 15:15:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 May 2011 13:15:04 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <BANLkTikFRc7d=Cs0Q5-623e=iiTE_R9o3A@mail.gmail.com>
Message-ID: <1305292501.3561.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But Lib/multiprocessing/connection.py does:
> 
>     def _send_bytes(self, buf):
>         # For wire compatibility with 3.2 and lower
>         n = len(buf)
>         self._send(struct.pack("=i", len(buf)))
>         # The condition is necessary to avoid "broken pipe" errors
>         # when sending a 0-length buffer if the other end closed the pipe.
>         if n > 0:
>             self._send(buf)
> 
> This is definitely not atomic.

Indeed, it isn't, Pipe objects are not meant to be safe against multiple
access. Queue objects (in multiprocessing/queues.py) use locks so they
are safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Fri May 13 15:17:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 13:17:12 +0000
Subject: [issue11965] Simplify context manager in os.popen
In-Reply-To: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za>
Message-ID: <1305292632.64.0.0687338280316.issue11965@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

After #12044, subprocess.Popen.__exit__ waits for process completion and closes streams.  Doesn?t that make wrap_close obsolete?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11965>
_______________________________________

From report at bugs.python.org  Fri May 13 15:19:00 2011
From: report at bugs.python.org (Alex Lai)
Date: Fri, 13 May 2011 13:19:00 +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: <1305292740.35.0.40224239601.issue12013@psf.upfronthosting.co.za>


Alex Lai <alex_lai at scotiacapital.com> added the comment:

No bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Fri May 13 15:19:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 13:19:19 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1305292759.16.0.621393871456.issue6011@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri May 13 15:20:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 13:20:41 +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: <1305292841.69.0.98735791425.issue12013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

All right.  Don?t hesitate to report any other bugs you find in the future.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Fri May 13 15:50:13 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 13 May 2011 13:50:13 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1305294613.2.0.759781143854.issue9516@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'll apply the patch late tonight (I won't be home until at least 22:30 CEST)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Fri May 13 15:58:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 13:58:19 +0000
Subject: [issue12070] Unlimited loop in sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

$ ./python -c "import sysconfig; sysconfig._parse_makefile('Makefile.loop')"

It loops on the following variables:

'DESTSHARED'='$(BINLIBDEST)/lib-dynload'
'INCLDIRSTOMAKE'='$(INCLUDEDIR) $(CONFINCLUDEDIR) $(INCLUDEPY) $(CONFINCLUDEPY)'
'CONFINCLUDEPY'='$(CONFINCLUDEDIR)/python$(LDVERSION)'
'DESTLIB'='$(LIBDEST)'
'INCLUDEPY'='$(INCLUDEDIR)/python$(LDVERSION)'
'MANDIR'='${datarootdir}/man'
'DESTDIRS'='$(exec_prefix) $(LIBDIR) $(BINLIBDEST) $(DESTSHARED)'
'CONFINCLUDEDIR'='$(exec_prefix)/include'
'exec_prefix'='${prefix}'
'LIBDIR'='${exec_prefix}/lib'
'LIBDEST'='$(SCRIPTDIR)/python$(VERSION)'
'INCLUDEDIR'='${prefix}/include'
'BINDIR'='${exec_prefix}/bin'
'LIBPC'='$(LIBDIR)/pkgconfig'
'datarootdir'='${prefix}/share'
'SCRIPTDIR'='$(prefix)/lib'
'BINLIBDEST'='$(LIBDIR)/python$(VERSION)'
'LIBPL'='$(LIBDEST)/config-$(LDVERSION)'
'MACHDESTLIB'='$(BINLIBDEST)'

I had the bug while trying to debug #6011.

----------
components: Library (Lib)
messages: 135909
nosy: haypo
priority: normal
severity: normal
status: open
title: Unlimited loop in sysconfig._parse_makefile()
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12070>
_______________________________________

From report at bugs.python.org  Fri May 13 16:04:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 14:04:52 +0000
Subject: [issue12070] Unlimited loop in sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <1305295492.38.0.84516603065.issue12070@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file21993/Makefile.loop

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12070>
_______________________________________

From report at bugs.python.org  Fri May 13 16:05:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 14:05:29 +0000
Subject: [issue12070] Unlimited loop in sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <1305295529.15.0.818590526435.issue12070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My OS is Debian Sid. Important note: I use LC_ALL=C and so ASCII locale encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12070>
_______________________________________

From report at bugs.python.org  Fri May 13 16:14:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 14:14:55 +0000
Subject: [issue12071] test_concurrent_futures hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_concurrent_futures of Python 3.3 (rev [6d8678555c04]) hangs on OpenIndiana. I dumped manually the tracebacks of the parent process (test_concurrent_futures) and of the 3 child processes. In the parent process, the test hangs when exiting the context manager:

---------------------------------------------
    def test_context_manager_shutdown(self):
        with futures.ProcessPoolExecutor(max_workers=5) as e:
            processes = e._processes
            self.assertEqual(list(e.map(abs, range(-5, 5))),
                             [5, 4, 3, 2, 1, 0, 1, 2, 3, 4])
            ####### HERE #########
        for p in processes:
            p.join()
---------------------------------------------

I may be related to issue #9205.

Have fun with the following tracebacks!

[123/354] test_concurrent_futures

=== Parent ===

Thread 0x000004af:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x000004ae:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x000004a0:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000049f:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000049e:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000049d:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000479:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000478:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000477:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000476:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000475:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000474:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000473:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000472:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000471:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000470:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046f:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046e:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046d:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000046c:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044d:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044c:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044b:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x0000044a:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000449:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000448:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000447:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000446:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000445:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/threading.py", line 851 in join
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 352 in shutdown
    self._queue_management_thread.join()
  File "/home/haypo/cpython/Lib/concurrent/futures/_base.py", line 570 in __exit__
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 164 in test_context_manager_shutdown
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 462 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in <module>
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

=== Child #1 =========

Thread 0x00000445:

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/threading.py", line 423 in wait
  File "/home/haypo/cpython/Lib/threading.py", line 685 in start
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 187 in _start_thread
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 107 in put
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 168 in _add_call_item_to_queue
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 206 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 115 in get
    self._rlock.acquire()
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 122 in _process_worker
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 118 in run
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 263 in _bootstrap
  File "/home/haypo/cpython/Lib/multiprocessing/forking.py", line 126 in __init__
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 134 in start
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 323 in _adjust_process_count
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 341 in submit
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in <listcomp>
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in _prime_executor
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 64 in setUp
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 460 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in <module>
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

=== Child #2 =========

Thread 0x00000445:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 117 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 122 in _process_worker
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 118 in run
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 263 in _bootstrap
  File "/home/haypo/cpython/Lib/multiprocessing/forking.py", line 126 in __init__
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 134 in start
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 323 in _adjust_process_count
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 341 in submit
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in <listcomp>
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in _prime_executor
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 64 in setUp
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 460 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in <module>
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

=== Child #3 =========

Thread 0x00000445:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 252 in _feed
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 364 in _recv
    chunk = read(self._handle, remaining)
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/home/haypo/cpython/Lib/multiprocessing/connection.py", line 260 in recv
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 378 in get
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 208 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

Current thread 0x00000001:
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 115 in get
    self._rlock.acquire()
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 122 in _process_worker
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 118 in run
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 263 in _bootstrap
  File "/home/haypo/cpython/Lib/multiprocessing/forking.py", line 126 in __init__
  File "/home/haypo/cpython/Lib/multiprocessing/process.py", line 134 in start
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 323 in _adjust_process_count
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 341 in submit
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in <listcomp>
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 77 in _prime_executor
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 64 in setUp
  File "/home/haypo/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/home/haypo/cpython/Lib/unittest/case.py", line 460 in run
  File "/home/haypo/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 105 in run
  File "/home/haypo/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/home/haypo/cpython/Lib/test/support.py", line 1099 in run
  File "/home/haypo/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/home/haypo/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/home/haypo/cpython/Lib/test/test_concurrent_futures.py", line 618 in test_main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 662 in main
  File "/home/haypo/cpython/Lib/test/regrtest.py", line 1625 in <module>
  File "/home/haypo/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/haypo/cpython/Lib/runpy.py", line 160 in _run_module_as_main

----------
components: Tests
messages: 135911
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures hangs on OpenIndiana
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12071>
_______________________________________

From report at bugs.python.org  Fri May 13 16:18:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 14:18:53 +0000
Subject: [issue12071] test_concurrent_futures.test_context_manager_shutdown()
	hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1305296333.99.0.723105652329.issue12071@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_concurrent_futures hangs on OpenIndiana -> test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12071>
_______________________________________

From report at bugs.python.org  Fri May 13 16:21:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 14:21:43 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1242212510.55.0.349129306137.issue6011@psf.upfronthosting.co.za>
Message-ID: <1305296503.92.0.219203923591.issue6011@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> 
status: closed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri May 13 16:23:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 May 2011 14:23:58 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1305296638.44.0.283005389069.issue8604@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Something's missing in all the implementations presented:
to make sure that the new version of the file is available afer a crash, fsync must be called on the containing directory after the rename.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri May 13 16:49:41 2011
From: report at bugs.python.org (dario frascatani)
Date: Fri, 13 May 2011 14:49:41 +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: <1305298181.82.0.676895648985.issue12013@psf.upfronthosting.co.za>


dario frascatani <dgfrascatani at gmail.com> added the comment:

I guys I have the same problem with solaris 10 and the pre-compiled package python-3.1.2 downloaded from sunfreeware.com

----------
nosy: +drdevious

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Fri May 13 16:52:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 14:52:31 +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: <1305298351.03.0.627880001403.issue12013@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you download a Python 3.1.3 from python.org (or better, clone the 3.1 repository from hg.python.org), try to compile it and report errors?  We can?t do anything for files provided by sunfreeware, but we can fix platform-specific problems if they come from our code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Fri May 13 17:09:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 15:09:15 +0000
Subject: [issue11617] Sporadic failure in test_httpservers
In-Reply-To: <1300640781.99.0.619640847889.issue11617@psf.upfronthosting.co.za>
Message-ID: <1305299355.04.0.257511683318.issue11617@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The issue looks to be fixed. Reopen if there are new failures.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11617>
_______________________________________

From report at bugs.python.org  Fri May 13 17:23:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 15:23:14 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1305300194.93.0.669618442821.issue11873@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> You are right that I got the regex wrong (I'm bad at regexes), but in
> fact it is fine the way it is.  Since there's no r, the regex is
> actually "ba[^/]$", which is exactly what I meant.

I would edit the string to reflect your meaning, then, otherwise other people may think too that the r was forgotten.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Fri May 13 17:24:27 2011
From: report at bugs.python.org (Milko Krachounov)
Date: Fri, 13 May 2011 15:24:27 +0000
Subject: [issue8604] Adding an atomic FS write API
In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za>
Message-ID: <1305300267.0.0.0166569082352.issue8604@psf.upfronthosting.co.za>


Milko Krachounov <python at milko.3mhz.net> added the comment:

> Something's missing in all the implementations presented:
> to make sure that the new version of the file is available afer 
> a crash, fsync must be called on the containing directory after 
> the rename.

I upgraded my proposed approach to include dir fsync, and to do a copy when backing up instead of rename (is that good?)

http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/66/blackherd/misc.py#L498

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8604>
_______________________________________

From report at bugs.python.org  Fri May 13 17:27:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 15:27:04 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1305300424.25.0.967159151913.issue11964@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It turns out that only one documentation block talks about the new indent behavior.  It was easy to add a versionchanged directive to that, but I think a complete patch would fix all mentions of the indent argument, after checking that all of encode/dump/dumps/Encoder.whatnot support the new behavior (there is a test for dumps only, I checked that dump works too but not the other ones).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11964>
_______________________________________

From report at bugs.python.org  Fri May 13 17:44:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 15:44:00 +0000
Subject: [issue11873] test_regexp() of test_compileall fails occassionally
In-Reply-To: <1303200742.44.0.692336710833.issue11873@psf.upfronthosting.co.za>
Message-ID: <1305301440.33.0.474664453751.issue11873@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> 
status: closed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11873>
_______________________________________

From report at bugs.python.org  Fri May 13 17:47:12 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 13 May 2011 15:47:12 +0000
Subject: [issue12071] test_concurrent_futures.test_context_manager_shutdown()
	hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1305301632.98.0.233915288084.issue12071@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/issue12071>
_______________________________________

From report at bugs.python.org  Fri May 13 17:48:10 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 13 May 2011 15:48:10 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1305301690.57.0.609174125826.issue9205@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/issue9205>
_______________________________________

From report at bugs.python.org  Fri May 13 17:48:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 15:48:13 +0000
Subject: [issue11377] Deprecate (remove?) platform.popen()
In-Reply-To: <1299086966.45.0.602666513721.issue11377@psf.upfronthosting.co.za>
Message-ID: <1305301693.43.0.294445610179.issue11377@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is it on purpose that there is a doc deprecation but no [Pending]DeprecationWarning?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11377>
_______________________________________

From report at bugs.python.org  Fri May 13 17:51:57 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 May 2011 15:51:57 +0000
Subject: [issue11377] Deprecate (remove?) platform.popen()
In-Reply-To: <1305301693.43.0.294445610179.issue11377@psf.upfronthosting.co.za>
Message-ID: <4DCD5399.2020600@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Is it on purpose that there is a doc deprecation but no [Pending]DeprecationWarning?

No, I guess just an oversight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11377>
_______________________________________

From report at bugs.python.org  Fri May 13 17:53:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2011 15:53:27 +0000
Subject: [issue11996] libpython.py: nicer py-bt output
In-Reply-To: <1304500095.82.0.965528459857.issue11996@psf.upfronthosting.co.za>
Message-ID: <E1QKugA-0000JI-Ku@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b340d1577dc5 by Victor Stinner in branch '3.2':
Issue #11996: libpython (gdb), replace "py-bt" command by "py-bt-full" and add
http://hg.python.org/cpython/rev/b340d1577dc5

New changeset 804abc2c60de by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11996: libpython (gdb), replace "py-bt" command by
http://hg.python.org/cpython/rev/804abc2c60de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11996>
_______________________________________

From report at bugs.python.org  Fri May 13 18:00:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 16:00:11 +0000
Subject: [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1305302411.11.0.876858416549.issue11786@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: closed -> pending
title: ConfigParser. -> ConfigParser.[Raw]ConfigParser optionxform()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11786>
_______________________________________

From report at bugs.python.org  Fri May 13 18:09:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 16:09:44 +0000
Subject: [issue11996] libpython.py: nicer py-bt output
In-Reply-To: <1304500095.82.0.965528459857.issue11996@psf.upfronthosting.co.za>
Message-ID: <1305302984.89.0.532205605068.issue11996@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Without any reaction from Dave Malcolm, I kept its name under the name "py-bt-full".

> I would also like a less verbose output for where, especially
> be able to hidden the value of the globals argument of
> PyEval_EvalCodeEx.

Well, I will maybe open a new issue for this one. But I consider that the work is done on this issue so I close it.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11996>
_______________________________________

From report at bugs.python.org  Fri May 13 18:12:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 16:12:10 +0000
Subject: [issue12069] test_signal.test_without_siginterrupt() failure on AMD64
	OpenIndiana 3.x
In-Reply-To: <1305241367.49.0.983669109712.issue12069@psf.upfronthosting.co.za>
Message-ID: <1305303130.36.0.403849119982.issue12069@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to reproduce the issue using regrtest.py -F test_signal. It is maybe a race condition, or another test has a border effect of test_signal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12069>
_______________________________________

From report at bugs.python.org  Fri May 13 18:34:55 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Fri, 13 May 2011 16:34:55 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1305304495.26.0.510686224632.issue10761@psf.upfronthosting.co.za>


Scott Leerssen <sleerssen at gmail.com> added the comment:

It turns out that my fix was at least one byte short of complete.  If the target pathname is a broken symlink, os.path.exists() returns False, and the OSError is raised.  I should have used os.path.lexists().  Also, I believe the same problem exists for the hardlink case a few lines below.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Fri May 13 18:57:08 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Fri, 13 May 2011 16:57:08 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1305305828.72.0.0214989644134.issue10761@psf.upfronthosting.co.za>


Scott Leerssen <sleerssen at gmail.com> added the comment:

here is a diff of a better fix based on the previous patch:


Index: tarfile.py
===================================================================
--- tarfile.py  (revision 49758)
+++ tarfile.py  (working copy)
@@ -2239,12 +2239,14 @@
         if hasattr(os, "symlink") and hasattr(os, "link"):
             # For systems that support symbolic and hard links.
             if tarinfo.issym():
-                if os.path.exists(targetpath):
+                if os.path.lexists(targetpath):
                     os.unlink(targetpath)
                 os.symlink(tarinfo.linkname, targetpath)
             else:
                 # See extract().
                 if os.path.exists(tarinfo._link_target):
+                    if os.path.lexists(targetpath):
+                        os.unlink(targetpath)
                     os.link(tarinfo._link_target, targetpath)
                 else:
                     self._extract_member(self._find_link_target(tarinfo), targetpath)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Fri May 13 18:58:17 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Fri, 13 May 2011 16:58:17 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1305305897.4.0.514779641023.issue10761@psf.upfronthosting.co.za>


Scott Leerssen <sleerssen at gmail.com> added the comment:

tests that verify the bug/fix:


    def test_extractall_broken_symlinks(self):
        # Test if extractall works properly when tarfile contains symlinks
        tempdir = os.path.join(TEMPDIR, "testsymlinks")
        temparchive = os.path.join(TEMPDIR, "testsymlinks.tar")
        os.mkdir(tempdir)
        try:
            source_file = os.path.join(tempdir,'source')
            target_file = os.path.join(tempdir,'symlink')
            with open(source_file,'w') as f:
                f.write('something\n')
            os.symlink(source_file, target_file)
            tar = tarfile.open(temparchive,'w')
            tar.add(target_file, arcname=os.path.basename(target_file))
            tar.close()
            # remove the real file
            os.unlink(source_file)
            # Let's extract it to the location which contains the symlink
            tar = tarfile.open(temparchive,'r')
            # this should not raise OSError: [Errno 17] File exists
            try:
                tar.extractall(path=tempdir)
            except OSError:
                self.fail("extractall failed with broken symlinked files")
            finally:
                tar.close()
        finally:
            os.unlink(temparchive)
            shutil.rmtree(TEMPDIR)

    def test_extractall_hardlinks(self):
        # Test if extractall works properly when tarfile contains symlinks
        TEMPDIR = tempfile.mkdtemp()
        tempdir = os.path.join(TEMPDIR, "testsymlinks")
        temparchive = os.path.join(TEMPDIR, "testsymlinks.tar")
        os.mkdir(tempdir)
        try:
            source_file = os.path.join(tempdir,'source')
            target_file = os.path.join(tempdir,'symlink')
            with open(source_file,'w') as f:
                f.write('something\n')
            os.link(source_file, target_file)
            tar = tarfile.open(temparchive,'w')
            tar.add(source_file, arcname=os.path.basename(source_file))
            tar.add(target_file, arcname=os.path.basename(target_file))
            tar.close()
            # Let's extract it to the location which contains the symlink
            tar = tarfile.open(temparchive,'r')
            # this should not raise OSError: [Errno 17] File exists
            try:
                tar.extractall(path=tempdir)
            except OSError:
                self.fail("extractall failed with linked files")
            finally:
                tar.close()
        finally:
            os.unlink(temparchive)
            shutil.rmtree(TEMPDIR)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Fri May 13 19:05:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 17:05:56 +0000
Subject: [issue12024] 2.6 svn and hg branches are out of sync
In-Reply-To: <1304724015.49.0.713905819899.issue12024@psf.upfronthosting.co.za>
Message-ID: <1305306356.31.0.495754749443.issue12024@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I guess release for stable branches (especially venerable branches in security mode) should be made from Subversion.  Who know what code could break without a meaningful sys.subversion?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12024>
_______________________________________

From report at bugs.python.org  Fri May 13 19:07:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 17:07:20 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1305306440.11.0.591931418623.issue12029@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/issue12029>
_______________________________________

From report at bugs.python.org  Fri May 13 19:08:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 17:08:23 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1305306503.58.0.761098277919.issue12043@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?it seems to?: does this come from the mailing list?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Fri May 13 19:08:51 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 13 May 2011 17:08:51 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1305217122.59.0.820210722215.issue12040@psf.upfronthosting.co.za>
Message-ID: <BANLkTimggYav2Z0OMXCWEf3E06OALADAew@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

That looks better. :)

btw, that eintr_retry utility probably deserves to be in a more
prominent place in the stdlib but I don't have a good suggestion as to
where at the moment.  I believe similar code exists in many places in
the code base.

If it is not going to be documented as an official
multiprocessing.util function, rename it to _eintr_retry().  that way
it'll be easier to move to a new place in the library if/when we do
want to make it public.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12040>
_______________________________________

From report at bugs.python.org  Fri May 13 19:09:58 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 May 2011 17:09:58 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1304966363.67.0.392142624447.issue12040@psf.upfronthosting.co.za>
Message-ID: <1305306598.13.0.230696925853.issue12040@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Just a detail, but with the last version, select is retried with the full timeout (note that the signal you're the most likely to receive is SIGCHLD and since it's ignored by default it won't cause EINTR, so this shouldn't happen too often).
By the way, it's not the first time EINTR-issues pop up: would it be possible/worth it/interesting to expose this kind of wrapper somewhere (even as a private API), or a context manager ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12040>
_______________________________________

From report at bugs.python.org  Fri May 13 19:12:34 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 13 May 2011 17:12:34 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1305306754.73.0.117794795247.issue12043@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Fri May 13 19:15:50 2011
From: report at bugs.python.org (H.)
Date: Fri, 13 May 2011 17:15:50 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1305306950.98.0.820868880987.issue2521@psf.upfronthosting.co.za>


H. <demirhan.ee at gmail.com> added the comment:

ImportError: No module named _weakrefset
Here are some references while i was trying to install Pinax framework.

http://paste.pound-python.org/show/6536/

And i saw that the _weakrefset.py is not included in the package. So I have copied from Python's source with version : 3.1.* to my d:\sosyal\ folder. and everything works fine.

----------
nosy: +bluag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Fri May 13 19:22:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 17:22:21 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305307341.92.0.934646145821.issue11948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

About Terry?s suggestion to change "This allows Python programs to modify or replace the module search path" to "After initialization, Python programs can modify sys.path": IMO the old text is talking about intent (modify the module search path) and the replacement about implementation (modify sys.path).  I prefer the former; what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri May 13 19:23:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 May 2011 17:23:48 +0000
Subject: [issue12071] test_concurrent_futures.test_context_manager_shutdown()
	hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1305307428.11.0.456397974845.issue12071@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Interesting.
There's something weird with the first child:

=== Child #1 =========

Thread 0x00000445:

Thread 0x00000444:
  File "/home/haypo/cpython/Lib/threading.py", line 237 in wait
    waiter.acquire()
  File "/home/haypo/cpython/Lib/threading.py", line 423 in wait
  File "/home/haypo/cpython/Lib/threading.py", line 685 in start
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 187 in _start_thread
  File "/home/haypo/cpython/Lib/multiprocessing/queues.py", line 107 in put
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 168 in _add_call_item_to_queue
  File "/home/haypo/cpython/Lib/concurrent/futures/process.py", line 206 in _queue_management_worker
  File "/home/haypo/cpython/Lib/threading.py", line 690 in run
  File "/home/haypo/cpython/Lib/threading.py", line 737 in _bootstrap_inner
  File "/home/haypo/cpython/Lib/threading.py", line 710 in _bootstrap

See the last thread created (0x00000445)?
0x00000444 bootstrapped 0x00000445, and is waiting for it to signal that it's running.
Since there's no backtrace for this thread, it means that it's stuck inside t_bootstrap or really early in the call stack (or didn't start at all?).
You don't have a coredump, do you?
I guess it's not reproductible either?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12071>
_______________________________________

From report at bugs.python.org  Fri May 13 19:25:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 17:25:13 +0000
Subject: [issue11377] Deprecate platform.popen()
In-Reply-To: <1299086966.45.0.602666513721.issue11377@psf.upfronthosting.co.za>
Message-ID: <1305307513.76.0.678503170675.issue11377@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

haypo asked me on IRC if I?d like to make a patch for this; I will, in some weeks.

With respect to the recent thread about deprecations and 2.7 ? 3.<latest> migrations, should this be a DeprecationWarning or PendingDeprecationWarning?  Neither is displayed by default, but using PDW would put the actual removal a version later.  I?m not sure about the timeframe here.

----------
assignee:  -> eric.araujo
resolution: fixed -> 
stage:  -> needs patch
status: closed -> open
title: Deprecate (remove?) platform.popen() -> Deprecate platform.popen()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11377>
_______________________________________

From report at bugs.python.org  Fri May 13 19:43:32 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 13 May 2011 17:43:32 +0000
Subject: [issue2521] ABC caches should use weak refs
In-Reply-To: <1206976350.45.0.982533625998.issue2521@psf.upfronthosting.co.za>
Message-ID: <1305308612.69.0.117057219599.issue2521@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

bluag: the script you run contains a list of some modules required to start Python
(I found a copy here: https://github.com/pinax/pinax/raw/master/scripts/pinax-boot.py )
This script is obviously out of date wrt the new version of Python. Please report this to the pinax project!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2521>
_______________________________________

From report at bugs.python.org  Fri May 13 20:08:36 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Fri, 13 May 2011 18:08:36 +0000
Subject: [issue10761] tarfile.extractall fails to overwrite symlinks
In-Reply-To: <1293063436.61.0.0994372418071.issue10761@psf.upfronthosting.co.za>
Message-ID: <1305310116.96.0.92370569314.issue10761@psf.upfronthosting.co.za>


Scott Leerssen <sleerssen at gmail.com> added the comment:

oops... I left some of my local edits in those tests.  be sure to fix the TEMPDIR use if you add these into the tarfile tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10761>
_______________________________________

From report at bugs.python.org  Fri May 13 20:10:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2011 18:10:15 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305310215.61.0.764196778846.issue11948@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I disagree (else I would not have suggested change ;-). First, I dislike 'This allows' on stylistic grounds, when there is a better alternative. It is rather wishy-washy: 'this allows' -- so what? As for the rest -- why not be specific? The whole paragraph is about sys.path, so it is not an hidden detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri May 13 20:11:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 13 May 2011 18:11:47 +0000
Subject: [issue12072] Missing parenthesis in c-api/buffer
	PyBuffer_FillContiguousStrides
In-Reply-To: <1305310307.77.0.353459071063.issue12072@psf.upfronthosting.co.za>
Message-ID: <1305310307.77.0.353459071063.issue12072@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up with http://mail.python.org/pipermail/docs/2011-April/004159.html here's a tiny patch to add a missing parenthesis.

----------
assignee: docs at python
components: Documentation
files: capi_buffer_PyBuffer_FillContiguousStrides-py27.patch
keywords: patch
messages: 135938
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Missing parenthesis in c-api/buffer PyBuffer_FillContiguousStrides
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file21994/capi_buffer_PyBuffer_FillContiguousStrides-py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12072>
_______________________________________

From report at bugs.python.org  Fri May 13 20:15:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 13 May 2011 18:15:35 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1305310535.78.0.662925446413.issue12043@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

nope, from a quick glance at the docstrings text and what's on the ReST documentation - was I a bit too catastrophic? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Fri May 13 20:17:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 18:17:25 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305310645.41.0.556776675691.issue11948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> First, I dislike 'This allows' on stylistic grounds
Fully agreed, sir!

> The whole paragraph is about sys.path, so it is not an hidden detail.
It may be that I miss context; I don?t actually know whether the paragraph is only about sys.path or about module search in general.  Apologies if my comments are only noise.  This is my last proposal:

?After initialization, Python programs can modify sys.path to modify or replace the module search path (except for built-in modules)?

If it?s redundant, then +1 to your earlier suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri May 13 20:18:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 May 2011 18:18:15 +0000
Subject: [issue12043] Update shutil documentation
In-Reply-To: <1304967545.46.0.442679433989.issue12043@psf.upfronthosting.co.za>
Message-ID: <1305310695.99.0.183830252872.issue12043@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No, it?s just the wording that made me think you were referring to other reports or to posts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12043>
_______________________________________

From report at bugs.python.org  Fri May 13 20:22:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2011 18:22:26 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305310946.93.0.983093850381.issue11948@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sandro, thank you for sticking with this. Seemingly simples issues sometimes 'explode' a bit. Having reviewed the patch, I think the it is ready to be committed.

?ric: if you were to commit this and, in the process, wanted to change sys.path back to 'this module search path' ('this' instead of 'the' to refer back to the definition of sys.path just given), I would not object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri May 13 20:22:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2011 18:22:55 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1305310975.77.0.506065843528.issue11948@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri May 13 20:36:04 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 May 2011 18:36:04 +0000
Subject: [issue11377] Deprecate platform.popen()
In-Reply-To: <1305307513.76.0.678503170675.issue11377@psf.upfronthosting.co.za>
Message-ID: <4DCD7A10.8060800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> haypo asked me on IRC if I?d like to make a patch for this; I will, in some weeks.
> 
> With respect to the recent thread about deprecations and 2.7 ? 3.<latest> migrations, should this be a DeprecationWarning or PendingDeprecationWarning?  Neither is displayed by default, but using PDW would put the actual removal a version later.  I?m not sure about the timeframe here.

Please follow the PEP 387 guidelines. We are starting the deprecation
process with 3.3. I don't think we need a PendingDeprecationWarning
in 3.3, but we might want to add one to 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11377>
_______________________________________

From report at bugs.python.org  Fri May 13 20:55:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 13 May 2011 18:55:11 +0000
Subject: [issue12068] test_logging failure in test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <1305312911.12.0.996238828337.issue12068@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12068>
_______________________________________

From report at bugs.python.org  Fri May 13 20:55:27 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 13 May 2011 18:55:27 +0000
Subject: [issue12068] test_logging failure in test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <1305312927.14.0.449851505748.issue12068@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution: duplicate -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12068>
_______________________________________

From report at bugs.python.org  Fri May 13 21:10:33 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Fri, 13 May 2011 19:10:33 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1305313833.64.0.19458243623.issue12042@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

I'll prepare the patch if davipo doesn't want to. I'm trying to become more comfortable with the patching process and this seems simple enough for me to handle.

----------
nosy: +jstadler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Sat May 14 00:37:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 22:37:22 +0000
Subject: [issue12070] Unlimited loop in sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <1305326242.23.0.973681559693.issue12070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, the problem is that the prefix variable value is seen as "bogus" ($/home/haypo/...: $ is a typo made by me!) and the variable is removed from variables. But other variables depend on the prefix and so we have an unlimited loop.

Possibles fixes:
 - raise an exception if a variable is "bogus"
 - detect loops: ensure that at least was removed during a step (and raise an exception if not)
 - keep "bogus" variables (add them to done)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12070>
_______________________________________

From report at bugs.python.org  Sat May 14 00:42:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 22:42:14 +0000
Subject: [issue12071] test_concurrent_futures.test_context_manager_shutdown()
	hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1305326534.76.0.517872113173.issue12071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I have "no more memory" errors on this VM especially on fork. test_concurrent_futures.test_context_manager_shutdown() failure should be related to a memory allocation error. I tried my faulthandler using SIGUSR1 to get more information, but send the send does kill the process instead of printing the traceback when test_concurrent_futures hangs, whereas it works as expected (dump tracebacks) a few tests before...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12071>
_______________________________________

From report at bugs.python.org  Sat May 14 01:01:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 23:01:57 +0000
Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on
	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

When you run the test suite manually and a test hangs, it would be nice to be able to dump immediatly the tracebacks of all threads without having to wait the timeout (which is 1 hour by default...).

Attached patch installs a signal handler for the SIGUSR1 signal. So "kill -USR1 <pid>" dumps immedialty the tracebacks without stopping the tests.

I already used it many times. It's useful and I did not notice any failure introduced by this change. I tested on Linux, FreeBSD and OpenIndiana. faulthandler.register() is not implemented on Windows (which doesn't have SIGUSR1 by the way).

I moved also the call to faulthandler.register() into main() to get the same behaviour using:
./python Lib/test/regrtest.py ...
./python -m test.regrtest ...
./python -m test ...

Actually, the last one doesn't enable faulthandler.

----------
components: Tests
files: regrtest_sigusr1.patch
keywords: patch
messages: 135947
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: use faulthandler to dump the tracebacks on SIGUSR1
versions: Python 3.3
Added file: http://bugs.python.org/file21995/regrtest_sigusr1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12073>
_______________________________________

From report at bugs.python.org  Sat May 14 01:12:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 13 May 2011 23:12:20 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <BANLkTinXqo5D6vm51AVoPEwneRVPoxmfKw@mail.gmail.com>
Message-ID: <20110513231204.GA83092@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@ Charles-Fran?ois Natali <report at bugs.python.org> wrote (2011-05-13 13:24+0200):
> I happily posted a reinit patch

I must say in advance that we have implemented our own thread
support 2003-2005 and i'm thus lucky not to need to use anything
else ever since.  So.  And of course i have no overview about
Python.  But i looked and saw no errors in the default path and
the tests run without errors.
Then i started to try your semaphore path which is a bit
problematic because Mac OS X doesn't offer anon sems ;).
(
By the way, in PyThread_acquire_lock_timed() these lines

    if (microseconds > 0)
                MICROSECONDS_TO_TIMESPEC(microseconds, ts);

result in these compiler warnings.

python/thread_pthread.h: In function ?PyThread_acquire_lock_timed?:
Python/thread_pthread.h:424: warning: ?ts.tv_sec? may be used
uninitialized in this function
Python/thread_pthread.h:424: warning: ?ts.tv_nsec? may be used
uninitialized in this function
)

#ifdef USE_SEMAPHORES
#define broken_sem_init broken_sem_init
static int broken_sem_init(sem_t **sem, int shared, unsigned int value) {
    int ret;
    auto char buffer[32];
    static long counter = 3000;
    sprintf(buffer, "%016ld", ++counter);
    *sem = sem_open(buffer, O_CREAT, (mode_t)0600, (unsigned int)value);
    ret = (*sem == SEM_FAILED) ? -1 : 0;
    //printf("BROKEN_SEM_INIT WILL RETURN %d (value=%u)\n", ret,value);
    return ret;
}
static int sem_timedwait(sem_t *sem, struct timespec *ts) {
    int success = -1, iters = 1000;
    struct timespec now, wait;
    printf("STARTING LOOP\n");
    for (;;) {
        if (sem_trywait(sem) == 0) {
            printf("TRYWAIT OK\n");
            success = 0;
            break;
        }
        wait.tv_sec = 0, wait.tv_nsec = 200 * 1000;
        //printf("DOWN "); fflush(stdout);
        nanosleep(&wait, NULL);
        MICROSECONDS_TO_TIMESPEC(0, now);
        //printf("WOKE UP NOW=%ld:%ld END=%ld:%ld\n", now.tv_sec,now.tv_nsec, ts->tv_sec,ts->tv_nsec);
        if (now.tv_sec > ts->tv_sec ||
            (now.tv_sec == ts->tv_sec && now.tv_nsec >= ts->tv_nsec))
            break;
        if (--iters < 0) {
            printf("BREAKING OFF LOOP, 1000 iterations\n");
            errno = ETIMEDOUT;
            break;
        }
    }
    return success;
}
#define sem_destroy sem_close

typedef struct _pthread_lock {
    sem_t               *sem;
    struct _pthread_lock*next;
    sem_t               sem_buf;
} pthread_lock;
#endif

plus all the changes the struct change implies, say.
Yes it's silly, but i wanted to test.  And this is the result:

== CPython 3.3a0 (default:804abc2c60de+, May 14 2011, 01:09:53) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-10.7.0-i386-64bit little-endian
==   /Users/steffen/src/cpython/build/test_python_19230
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=0, quiet=0)
Using random seed 1362049
[1/1] test_threading
STARTING LOOP
test_acquire_contended (test.test_threading.LockTests) ... ok
test_acquire_destroy (test.test_threading.LockTests) ... ok
test_acquire_release (test.test_threading.LockTests) ... ok
test_constructor (test.test_threading.LockTests) ... ok
test_different_thread (test.test_threading.LockTests) ... ok
test_reacquire (test.test_threading.LockTests) ... ok
test_state_after_timeout (test.test_threading.LockTests) ... ok
test_thread_leak (test.test_threading.LockTests) ... ok
test_timeout (test.test_threading.LockTests) ... STARTING LOOP
TRYWAIT OK
FAIL
test_try_acquire (test.test_threading.LockTests) ... ok
test_try_acquire_contended (test.test_threading.LockTests) ... ok
test_with (test.test_threading.LockTests) ... ok
test__is_owned (test.test_threading.PyRLockTests) ... ok
test_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_acquire_destroy (test.test_threading.PyRLockTests) ... ok
test_acquire_release (test.test_threading.PyRLockTests) ... ok
test_constructor (test.test_threading.PyRLockTests) ... ok
test_different_thread (test.test_threading.PyRLockTests) ... ok
test_reacquire (test.test_threading.PyRLockTests) ... ok
test_release_unacquired (test.test_threading.PyRLockTests) ... ok
test_thread_leak (test.test_threading.PyRLockTests) ... ok
test_timeout (test.test_threading.PyRLockTests) ... STARTING LOOP
TRYWAIT OK
FAIL
test_try_acquire (test.test_threading.PyRLockTests) ... ok
test_try_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_with (test.test_threading.PyRLockTests) ... ok
test__is_owned (test.test_threading.CRLockTests) ... ok
test_acquire_contended (test.test_threading.CRLockTests) ... ok
test_acquire_destroy (test.test_threading.CRLockTests) ... ok
test_acquire_release (test.test_threading.CRLockTests) ... ok
test_constructor (test.test_threading.CRLockTests) ... ok
test_different_thread (test.test_threading.CRLockTests) ... ok
test_reacquire (test.test_threading.CRLockTests) ... ok
test_release_unacquired (test.test_threading.CRLockTests) ... ok
test_thread_leak (test.test_threading.CRLockTests) ... BREAKING OFF LOOP, 1000 iterations
Timeout (1:00:00)!
Thread 0x00007fff70677ca0:
  File "/Users/steffen/src/cpython/Lib/test/lock_tests.py", line 17 in _wait
  File "/Users/steffen/src/cpython/Lib/test/lock_tests.py", line 52 in wait_for_finished
  File "/Users/steffen/src/cpython/Lib/test/lock_tests.py", line 152 in test_thread_leak
  File "/Users/steffen/src/cpython/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/Users/steffen/src/cpython/Lib/unittest/case.py", line 462 in run
  File "/Users/steffen/src/cpython/Lib/unittest/case.py", line 514 in __call__
  File "/Users/steffen/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/Users/steffen/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/steffen/src/cpython/Lib/unittest/suite.py", line 105 in run
  File "/Users/steffen/src/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/Users/steffen/src/cpython/Lib/unittest/runner.py", line 168 in run
  File "/Users/steffen/src/cpython/Lib/test/support.py", line 1187 in _run_suite
  File "/Users/steffen/src/cpython/Lib/test/support.py", line 1213 in run_unittest
  File "/Users/steffen/src/cpython/Lib/test/test_threading.py", line 748 in test_main
  File "/Users/steffen/src/cpython/Lib/test/regrtest.py", line 1044 in runtest_inner
  File "/Users/steffen/src/cpython/Lib/test/regrtest.py", line 838 in runtest
  File "/Users/steffen/src/cpython/Lib/test/regrtest.py", line 662 in main
  File "/Users/steffen/src/cpython/Lib/test/__main__.py", line 13 in <module>
  File "/Users/steffen/src/cpython/Lib/runpy.py", line 73 in _run_code
  File "/Users/steffen/src/cpython/Lib/runpy.py", line 160 in _run_module_as_main

Hope that helps a bit. B?illement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat May 14 01:16:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 23:16:00 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The full test suite has something like 354 tests. regrtest writes one line per test, and if you use Python compiled in debug mode you have much more lines because of "[123 refs]" lines written by subprocesses.

It's difficult to check if a previous test failed or not. If your terminal has a small backlog (e.g. 200 lines), it is maybe just not possible to know. In buildbot logs, it is also hard to search the first failure because the log is very verbose.

Attached patch adds " -- 1 failure" suffix after the first failure. If you use the -j option, the number of failure is written directly (because the test name is only printed after the test is done). By default, the counter is incremented *after* the failure.

--

Example (I modified test_os to ensure that it fails):

marge$ ./python -m test test_os test_sys test_os test_sys
[1/4] test_os
test test_os crashed -- Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/regrtest.py", line 1047, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/haypo/prog/HG/cpython/Lib/test/test_os.py", line 5, in <module>
    assert 1 == 0
AssertionError

[2/4] test_sys -- 1 failure
[37703 refs]
[37701 refs]
[37954 refs]
[37919 refs]
[3/4] test_os -- 1 failure
test test_os crashed -- Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/regrtest.py", line 1047, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/home/haypo/prog/HG/cpython/Lib/test/test_os.py", line 5, in <module>
    assert 1 == 0
AssertionError

[4/4] test_sys -- 2 failures
[37703 refs]
[37701 refs]
[37954 refs]
[37919 refs]
2 tests OK.
1 test failed:
    test_os
[98160 refs]

----------
components: Tests
files: regrtest_failures.patch
keywords: patch
messages: 135949
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: display the current number of failures
versions: Python 3.3
Added file: http://bugs.python.org/file21996/regrtest_failures.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Sat May 14 01:17:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 23:17:49 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <1305328669.25.0.961477092509.issue12074@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #12073.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Sat May 14 01:17:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2011 23:17:56 +0000
Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on
	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1305328676.39.0.747888631932.issue12073@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #12074.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12073>
_______________________________________

From report at bugs.python.org  Sat May 14 03:17:51 2011
From: report at bugs.python.org (Ricky Zhou)
Date: Sat, 14 May 2011 01:17:51 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1305335871.85.0.437296600059.issue1475523@psf.upfronthosting.co.za>


Changes by Ricky Zhou <ricky at rzhou.org>:


----------
nosy: +ricky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Sat May 14 04:16:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 May 2011 02:16:19 +0000
Subject: [issue11731] Simplify email API via 'policy' objects
In-Reply-To: <1301597340.87.0.239759427177.issue11731@psf.upfronthosting.co.za>
Message-ID: <1305339379.98.0.461694662741.issue11731@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11731>
_______________________________________

From report at bugs.python.org  Sat May 14 05:53:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 03:53:18 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <E1QL5um-0008EK-D1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5b0fecd2eba0 by Ezio Melotti in branch '2.7':
#5723: Improve json tests to be executed with and without accelerations.
http://hg.python.org/cpython/rev/5b0fecd2eba0

New changeset c2853a54b29e by Ezio Melotti in branch '3.1':
#5723: Improve json tests to be executed with and without accelerations.
http://hg.python.org/cpython/rev/c2853a54b29e

New changeset 63fb2b811c9d by Ezio Melotti in branch '3.2':
#5723: merge with 3.1.
http://hg.python.org/cpython/rev/63fb2b811c9d

New changeset afdc06f2552f by Ezio Melotti in branch 'default':
#5723: merge with 3.2.
http://hg.python.org/cpython/rev/afdc06f2552f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Sat May 14 05:55:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 03:55:31 +0000
Subject: [issue5723] Incomplete json tests
In-Reply-To: <1239205406.15.0.353111609778.issue5723@psf.upfronthosting.co.za>
Message-ID: <1305345331.49.0.693043559965.issue5723@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5723>
_______________________________________

From report at bugs.python.org  Sat May 14 07:22:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 May 2011 05:22:15 +0000
Subject: [issue12038] assertEqual doesn't display newline differences quite
	well
In-Reply-To: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>
Message-ID: <1305350535.66.0.637054794453.issue12038@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A possible fix is to condense the output by omitting stuff in the center rather than as the end:
"x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx...x\nx\nx\nx\nx\nx\nx\nx\nx\nx\n"
"x\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx\nx...x\nx\nx\nx\nx\nx\nx\nx\nx\nx\r\n"
would be clear.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12038>
_______________________________________

From report at bugs.python.org  Sat May 14 07:44:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 05:44:25 +0000
Subject: [issue7960] test.support.captured_output has invalid docstring example
In-Reply-To: <1266528241.14.0.253850913596.issue7960@psf.upfronthosting.co.za>
Message-ID: <E1QL7eK-0001It-0u@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 459e2c024420 by Ezio Melotti in branch '2.7':
#7960: fix docstrings for captured_output and captured_stdout.
http://hg.python.org/cpython/rev/459e2c024420

New changeset c2126d89c29b by Ezio Melotti in branch '3.1':
#7960: fix docstrings for captured_output and captured_stdout.
http://hg.python.org/cpython/rev/c2126d89c29b

New changeset 18a192ae6db9 by Ezio Melotti in branch '3.2':
#7960: merge with 3.1.
http://hg.python.org/cpython/rev/18a192ae6db9

New changeset 7517add4aec9 by Ezio Melotti in branch 'default':
#7960: merge with 3.2.
http://hg.python.org/cpython/rev/7517add4aec9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7960>
_______________________________________

From report at bugs.python.org  Sat May 14 07:49:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 05:49:30 +0000
Subject: [issue7960] test.support.captured_output has invalid docstring example
In-Reply-To: <1266528241.14.0.253850913596.issue7960@psf.upfronthosting.co.za>
Message-ID: <1305352170.12.0.113408986569.issue7960@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I fixed the docstring, however I think captured_output should be renamed _captured_output, since it only works with sys.stdout/in/err and there are already 3 other functions (in 3.2/3.3) that use captured_output to replace the 3 std* streams.  There's no reason to document and use it elsewhere.
Georg, what do you think?

----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7960>
_______________________________________

From report at bugs.python.org  Sat May 14 07:52:26 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 14 May 2011 05:52:26 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1305352346.65.0.988066477054.issue9516@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sat May 14 08:24:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 06:24:43 +0000
Subject: [issue11979] Minor improvements to the Sockets readme: typos,
	wording and sphinx features usage
In-Reply-To: <1304344252.29.0.0856006463682.issue11979@psf.upfronthosting.co.za>
Message-ID: <E1QL8HJ-0003U2-Sg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4081f326e46c by Ezio Melotti in branch '2.7':
#11979: improve wording and markup in sockets howto. Patch by Xavier Morel.
http://hg.python.org/cpython/rev/4081f326e46c

New changeset 85b9ad8b219b by Ezio Melotti in branch '3.1':
#11979: improve wording and markup in sockets howto. Patch by Xavier Morel.
http://hg.python.org/cpython/rev/85b9ad8b219b

New changeset bc251b65de1d by Ezio Melotti in branch '3.2':
#11979: merge with 3.1.
http://hg.python.org/cpython/rev/bc251b65de1d

New changeset 4b122cac7ac5 by Ezio Melotti in branch 'default':
#11979: merge with 3.2.
http://hg.python.org/cpython/rev/4b122cac7ac5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11979>
_______________________________________

From report at bugs.python.org  Sat May 14 08:25:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 06:25:34 +0000
Subject: [issue11979] Minor improvements to the Sockets readme: typos,
	wording and sphinx features usage
In-Reply-To: <1304344252.29.0.0856006463682.issue11979@psf.upfronthosting.co.za>
Message-ID: <1305354334.97.0.574146546969.issue11979@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patches!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11979>
_______________________________________

From report at bugs.python.org  Sat May 14 08:28:26 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 14 May 2011 06:28:26 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1305354506.54.0.391094686801.issue9516@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Attached the backport to 2.7 for my v2 patch.

----------
Added file: http://bugs.python.org/file21997/issue9516-v2-python2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sat May 14 08:36:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 06:36:59 +0000
Subject: [issue6191] HTMLParser attribute parsing - 2 test cases when it fails
In-Reply-To: <1244101614.1.0.195769853623.issue6191@psf.upfronthosting.co.za>
Message-ID: <1305355019.35.0.98276170167.issue6191@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

What I described in my previous message is what Firefox does.  If you think this should be changed, I suggest you to open another issue, possibly attaching a test case with the desired behavior and a patch to change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6191>
_______________________________________

From report at bugs.python.org  Sat May 14 08:56:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 06:56:30 +0000
Subject: [issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr
In-Reply-To: <1304354217.95.0.422937158098.issue11981@psf.upfronthosting.co.za>
Message-ID: <1305356190.21.0.858425080406.issue11981@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I double checked the code on py3k and I think the second occurrence can be removed.

----------
nosy: +alanmcintyre
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11981>
_______________________________________

From report at bugs.python.org  Sat May 14 09:16:32 2011
From: report at bugs.python.org (kai zhu)
Date: Sat, 14 May 2011 07:16:32 +0000
Subject: [issue12075] python3.2 memory leak when setting integer key in
	dictionary
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu at ugcs.caltech.edu>:

i'm using the latest debian unstable python3.2 build on colinux (2011, may, 14)

## leak.py
## >>> import imp, leak; imp.reload(leak)
## will leak ~2.5mb per reload
## on i386 debian unstable machine (according to top).
## in my real world app (an automatic build system),
## i run out of memory after a number reloads :(
class Foo(object): pass
Foo.leaky_dictionary = {}
for aa in range(256):
  for bb in range(256):
    Foo.leaky_dictionary[(bb << 8) | aa] = None


$ python3.2
Python 3.2.1a0 (default, May  5 2011, 00:47:12)
[GCC 4.6.1 20110428 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp, leak; imp.reload(leak) ## 11mb
<module 'leak' from 'leak.py'>
>>> import imp, leak; imp.reload(leak) ## 13mb
<module 'leak' from 'leak.py'>
>>> import imp, leak; imp.reload(leak) ## 16mb
<module 'leak' from 'leak.py'>
>>> import imp, leak; imp.reload(leak) ## 19mb
<module 'leak' from 'leak.py'>

----------
messages: 135961
nosy: kaizhu
priority: normal
severity: normal
status: open
title: python3.2 memory leak when setting integer key in dictionary
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12075>
_______________________________________

From report at bugs.python.org  Sat May 14 09:22:07 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 May 2011 07:22:07 +0000
Subject: [issue12071] test_concurrent_futures.test_context_manager_shutdown()
	hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1305357727.67.0.917561703796.issue12071@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

This makes sense.
I was suspecting a system limit exhaustion, maybe OOM or maximum number of threads, something like that.
But at least on Linux, in OOM condition, the process would either get nuked by the OOM-killer, or pthread_create would bail out with ENOMEM (when allocating the stack for example), so we would be able to - somewhat - catch the error and get an exception (well, OOM condition is also often a sort of "undefined behaviour", so we can't really make a guarantee on the state of the interpreter when it's hit).
Out of curioisity, could you try the attached test to see how it behaves on your VM?
Usage: ./test_thread_oom <number of threads to create>
On Linux it fails with ENOMEM "Resource temporarily unavailable".

----------
Added file: http://bugs.python.org/file21998/test_thread_oom.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12071>
_______________________________________

From report at bugs.python.org  Sat May 14 09:55:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 07:55:55 +0000
Subject: [issue12075] python3.2 memory leak when setting integer key in
	dictionary
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1305359755.21.0.654571655672.issue12075@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think this has to do with class attributes and reload():

wolf at hp:~/dev/py/py3k$ cat leak.py
class Foo: pass
Foo.l = list(range(65535))

wolf at hp:~/dev/py/py3k$ ./python 
Python 3.3a0 (default:4b122cac7ac5+, May 14 2011, 10:01:13) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp, leak; imp.reload(leak)
<module 'leak' from 'leak.py'>
[189091 refs]
>>> imp.reload(leak)
<module 'leak' from 'leak.py'>
[254649 refs]
>>> imp.reload(leak)
<module 'leak' from 'leak.py'>
[320207 refs]
>>> imp.reload(leak)
<module 'leak' from 'leak.py'>
[385765 refs]
>>> import gc; gc.collect()
28
[123927 refs]

However calling gc.collect() explicitly seems to fix the problem.

----------
nosy: +ezio.melotti
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12075>
_______________________________________

From report at bugs.python.org  Sat May 14 10:00:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 14 May 2011 08:00:28 +0000
Subject: [issue12075] python3.2 memory leak when setting integer key in
	dictionary
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1305360028.21.0.320760957369.issue12075@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's simply because all classes form a cycle (Foo -> Foo.__mro__ -> Foo)
A class and class attributes can only be freed with gc.collect().
Did you disable the garbage collector?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12075>
_______________________________________

From report at bugs.python.org  Sat May 14 10:26:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 May 2011 08:26:15 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <20110513231204.GA83092@sherwood.local>
Message-ID: <BANLkTi=n6VJN9K_+q7gkhwSn35vJwGsF4g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello Steffen,

First, thanks for testing this on OS-X: I only have access to Linux
systems (I tested both the semaphore and the emulated semaphore
paths).

If I understand correctly, the patch works fine with the default build
option on OS-X.
Then, you're saying that OS-X doesn't have POSIX unnamed semaphores:
this means that the default build uses the mutex+condition variable
version. Am I correct?
But I don't understand the last part of your message.
Do you mean that you implemented your own version of the semaphore
path using named semaphores, and that it fails with my patch (well,
your adapted version of it) ?
If yes, then you'll understand that I can't comment on this, since
it's not my code :-)
But after a quick look at the code you posted, I think that your
acquire code is broken:
sem_timedwait(timeout) if not the same as trying sem_trywait multiple
times until timeout expires: in case of contention, this will fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat May 14 13:25:53 2011
From: report at bugs.python.org (Chris Paton)
Date: Sat, 14 May 2011 11:25:53 +0000
Subject: [issue12076] IDLE v.3.2 crashing randomly on MacOSX 10.6.7
In-Reply-To: <1305372352.94.0.545379842287.issue12076@psf.upfronthosting.co.za>
Message-ID: <1305372352.94.0.545379842287.issue12076@psf.upfronthosting.co.za>


New submission from Chris Paton <chrispaton2005 at gmail.com>:

I don't know much about Python (in fact, I'm a noob) so not understanding much of the technical lingo. I've installed Python 3.2, and Active TCL 8.5.9 on my machine. IDLE crashes at random points - compiling, saving, loading or even just typing! Why is this? What can i do to get it working? There is no error message, I just get my spinning beach ball and then I have to force quit the program, so it doesn't seem to be anything official. Any help at all would be great, I really need to get this going for my thesis project!

----------
components: IDLE
messages: 135966
nosy: Chris.Paton
priority: normal
severity: normal
status: open
title: IDLE v.3.2 crashing randomly on MacOSX 10.6.7
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12076>
_______________________________________

From report at bugs.python.org  Sat May 14 13:35:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 14 May 2011 11:35:35 +0000
Subject: [issue12076] IDLE v.3.2 crashing randomly on MacOSX 10.6.7
In-Reply-To: <1305372352.94.0.545379842287.issue12076@psf.upfronthosting.co.za>
Message-ID: <1305372935.24.0.759496669452.issue12076@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Hello,
The Python issue tracker is not here to get help.
You will have better answers from friendly people if you ask your question on the comp.lang.python newsgroup, or the python-list mailing list: http://www.python.org/community/lists/

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12076>
_______________________________________

From report at bugs.python.org  Sat May 14 13:50:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 May 2011 11:50:34 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1305292501.3561.24.camel@localhost.localdomain>
Message-ID: <BANLkTi=sw1pdk_r5haUYbtiGZGfto68SMw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Indeed, it isn't, Pipe objects are not meant to be safe against multiple
> access. Queue objects (in multiprocessing/queues.py) use locks so they
> are safe.

But if the write to the Pipe is not atomic, then the select isn't safe.
select will return as soon as some data is available for reading. So
let's say this happens:
parent process waiting inside Connection.recv() on poll():
def recv(self, sentinels=None):
        if sentinels:
            self._poll(-1.0, sentinels)
        buf = self._recv_bytes()
        return pickle.loads(buf.getbuffer())

worker process, inside Connection.send():
def send_bytes(self, buf):
        n = len(buf)
        self._send(struct.pack("=i", len(buf)))
[crash]
        # The condition is necessary to avoid "broken pipe" errors
        # when sending a 0-length buffer if the other end closed the pipe.
        if n > 0:
            self._send(buf)

In the parent process, _poll() will return self._handle as readable as
soon as len(buf) has been sent by the worker process. Thus,
Connection.recv_bytes() will be called:

    def _recv_bytes(self, maxsize=None):
        buf = self._recv(4)
        size, = struct.unpack("=i", buf.getvalue())
        if maxsize is not None and size > maxsize:
            return None
        return self._recv(size)

The first _recv() will succeed, since the length is in the Pipe.
The second one, however, will remain stuck on the read from the
pipe/unix socket, because there's no more data.
This can be reproduced easily by adding a short sleep right after the
sending of the length of the buffer inside send_bytes(), and then
sending a SIGKILL to a worker process.
(Also, I now remember why I made the comment about the handle being
read after the select, I spotted this earlier but completely forgot
about it afterwards...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Sat May 14 13:57:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 11:57:28 +0000
Subject: [issue7960] test.support.captured_output has invalid docstring example
In-Reply-To: <1266528241.14.0.253850913596.issue7960@psf.upfronthosting.co.za>
Message-ID: <E1QLDTL-0008BR-GA@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ec35f86efb0d by Ezio Melotti in branch 'default':
Merge with 3.2 and also remove captured_output from __all__ (see #7960).
http://hg.python.org/cpython/rev/ec35f86efb0d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7960>
_______________________________________

From report at bugs.python.org  Sat May 14 13:59:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 11:59:09 +0000
Subject: [issue7960] test.support.captured_output has invalid docstring example
In-Reply-To: <1266528241.14.0.253850913596.issue7960@psf.upfronthosting.co.za>
Message-ID: <1305374349.82.0.294499124312.issue7960@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7960>
_______________________________________

From report at bugs.python.org  Sat May 14 14:21:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 12:21:44 +0000
Subject: [issue12050] unconsumed_tail of zlib.Decompress is not always cleared
	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <E1QLDqo-0001lL-SL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6a45567c7245 by Nadeem Vawda in branch '3.1':
Issue #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail
http://hg.python.org/cpython/rev/6a45567c7245

New changeset 49c998a88777 by Nadeem Vawda in branch '3.2':
Merge: #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail
http://hg.python.org/cpython/rev/49c998a88777

New changeset 088e5d705171 by Nadeem Vawda in branch 'default':
Merge: #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail
http://hg.python.org/cpython/rev/088e5d705171

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12050>
_______________________________________

From report at bugs.python.org  Sat May 14 14:29:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 12:29:58 +0000
Subject: [issue12050] unconsumed_tail of zlib.Decompress is not always cleared
	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <E1QLDyn-0002Bq-68@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 24543f7a87ce by Nadeem Vawda in branch '2.7':
Issue #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail
http://hg.python.org/cpython/rev/24543f7a87ce

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12050>
_______________________________________

From report at bugs.python.org  Sat May 14 14:36:38 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 14 May 2011 12:36:38 +0000
Subject: [issue12050] unconsumed_tail of zlib.Decompress is not always cleared
	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <1305376598.89.0.580455144267.issue12050@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The code has been fixed. Once again, thanks for the bug report.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12050>
_______________________________________

From report at bugs.python.org  Sat May 14 15:28:24 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 14 May 2011 13:28:24 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1305379704.63.0.514396449406.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Is there anything preventing this patch from being merged?

----------
nosy: +Darren.Dale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat May 14 15:56:26 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Sat, 14 May 2011 13:56:26 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

There are three sources of information for the descriptor protocol:
- Data model reference (Doc/reference/datamodel.rst)
- Descriptor HowTo guide (Doc/howto/descriptor.rst)
- PEP 252

A developer who already knows descriptor tipically reads the first one:
object.__get__(self, instance, owner) "... owner is always the owner class ..."
Reading a bit further there are the ways a descriptor can be called, and the "direct call" is x.__get__(a). That is, without the third argument (owner) specified.

The how-to definition is slightly different:
descr.__get__(self, obj, type=None) --> value
Here the arguments have different names ("type" shadowing the type bultin) and it seems to be implied that the third argument is optional. The ClassMethod example at the end of the document seems to confirm this:
def __get__(self, obj, klass=None):
(though another example doesn't).
And the method contains an explicit check on klass being None.
Also it could be confusing that through the examples in the same document many different names are used for the same argument (type, objtype, klass), and all different than the name used in the reference.

Lastly the PEP is more explicit:
__get__(): a function callable with one or two arguments. [...] When X is None, the optional second argument, T, should be meta-object. [...] When both X and T are specified ...

One more quirk: the reference explains the distinction between data and non-data descriptors, though says nothing about __set__ raising AttributeError for read-only data descriptors.

My proposal:
- use the same names for __get__ arguments throughout the documentation (both the reference and the tutorial), e.g. __get__(self, instance, owner)
- decide whether the third argument should be optional, or state the common usage in the reference, and fix accordingly the examples in the howto
- explain data, non-data and read-only descriptors in the __set__ reference, or more simply, how the defintion of __set__ affects these things.

----------
assignee: docs at python
components: Documentation
messages: 135974
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: Harmonizing descriptor protocol documentation
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Sat May 14 17:04:53 2011
From: report at bugs.python.org (Andriy Rysin)
Date: Sat, 14 May 2011 15:04:53 +0000
Subject: [issue12078] re.sub() replaces only several matches
Message-ID: <1305385493.13.0.0440581488003.issue12078@psf.upfronthosting.co.za>


Changes by Andriy Rysin <arysin at gmail.com>:


----------
components: Regular Expressions
files: repl.sh
nosy: arysin
priority: normal
severity: normal
status: open
title: re.sub() replaces only several matches
versions: Python 3.1
Added file: http://bugs.python.org/file21999/repl.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12078>
_______________________________________

From report at bugs.python.org  Sat May 14 17:05:27 2011
From: report at bugs.python.org (Andriy Rysin)
Date: Sat, 14 May 2011 15:05:27 +0000
Subject: [issue12078] re.sub() replaces only several matches
Message-ID: <1305385527.09.0.59445299929.issue12078@psf.upfronthosting.co.za>


Changes by Andriy Rysin <arysin at gmail.com>:


Added file: http://bugs.python.org/file22000/repl.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12078>
_______________________________________

From report at bugs.python.org  Sat May 14 17:05:40 2011
From: report at bugs.python.org (Andriy Rysin)
Date: Sat, 14 May 2011 15:05:40 +0000
Subject: [issue12078] re.sub() replaces only several matches
Message-ID: <1305385540.73.0.0280012865985.issue12078@psf.upfronthosting.co.za>


Changes by Andriy Rysin <arysin at gmail.com>:


Added file: http://bugs.python.org/file22001/test.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12078>
_______________________________________

From report at bugs.python.org  Sat May 14 17:07:00 2011
From: report at bugs.python.org (Andriy Rysin)
Date: Sat, 14 May 2011 15:07:00 +0000
Subject: [issue12078] re.sub() replaces only several matches
In-Reply-To: <1305385620.83.0.961543028277.issue12078@psf.upfronthosting.co.za>
Message-ID: <1305385620.83.0.961543028277.issue12078@psf.upfronthosting.co.za>


New submission from Andriy Rysin <arysin at gmail.com>:

When trying to replace strings with parenthesis (in the given example - alternative writing of the words in Ukrainian) the sed replace performs correctly replacing all occurrences, while python3 re.sub() function replaces only first two

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12078>
_______________________________________

From report at bugs.python.org  Sat May 14 17:47:14 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 May 2011 15:47:14 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1305388034.48.0.712014918295.issue5231@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Sat May 14 17:47:51 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 May 2011 15:47:51 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1305388071.72.0.976616483704.issue5231@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Unassigning.  Sorry;  no time for this at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Sat May 14 17:52:12 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 May 2011 15:52:12 +0000
Subject: [issue10581] Review and document string format accepted in numeric
	data type constructors
In-Reply-To: <1291053358.57.0.165550567454.issue10581@psf.upfronthosting.co.za>
Message-ID: <1305388332.89.0.401981835893.issue10581@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I find it convenient to use int(), float() etc. for data validation.

Me too.  This is why I'd still be happiest with int and float not accepting non-ASCII digits at all.  (And also why the recent suggestions to allow extra underscores in int and float input make me uneasy.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10581>
_______________________________________

From report at bugs.python.org  Sat May 14 18:20:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 May 2011 16:20:50 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1305379704.63.0.514396449406.issue11610@psf.upfronthosting.co.za>
Message-ID: <BANLkTikTOrcXw8dog1rwHGm98T2YaL31Jg@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/14 Darren Dale <report at bugs.python.org>:
>
> Darren Dale <dsdale24 at gmail.com> added the comment:
>
> Is there anything preventing this patch from being merged?

I have to make time to think about the API a bit more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat May 14 19:23:03 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Sat, 14 May 2011 17:23:03 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1305393783.08.0.989730109903.issue12042@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22002/issue12042_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Sat May 14 19:24:10 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Sat, 14 May 2011 17:24:10 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1305393850.83.0.988673186904.issue12042@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

Patch is up for 2.7, minor change in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Sat May 14 19:26:53 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 14 May 2011 17:26:53 +0000
Subject: [issue12078] re.sub() replaces only several matches
In-Reply-To: <1305385620.83.0.961543028277.issue12078@psf.upfronthosting.co.za>
Message-ID: <1305394013.56.0.331135313674.issue12078@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Argument 4 of re.sub is the maximum number of replacements, NOT flags:

Help on function sub in module re:

sub(pattern, repl, string, count=0, flags=0)
    Return the string obtained by replacing the leftmost
    non-overlapping occurrences of the pattern in string by the
    replacement repl.  repl can be either a string or a callable;
    if a string, backslash escapes in it are processed.  If it is
    a callable, it's passed the match object and must return
    a replacement string to be used.

re.I is 2, so you're telling it to perform at most 2 replacements.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12078>
_______________________________________

From report at bugs.python.org  Sat May 14 20:11:42 2011
From: report at bugs.python.org (Kasun Herath)
Date: Sat, 14 May 2011 18:11:42 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1305396702.5.0.163752229407.issue8809@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

I added a test to smtpnet and submitting a separate patch for it as my test_smtpnet.py file was old and could have had conflicts.

I didn't use keys and certificates for the SSLContext as those would have to be shipped with the source. Looking forward for reviews and suggestions.

----------
Added file: http://bugs.python.org/file22003/smtp_sslcontext_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Sat May 14 20:27:54 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 14 May 2011 18:27:54 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <BANLkTikTOrcXw8dog1rwHGm98T2YaL31Jg@mail.gmail.com>
Message-ID: <BANLkTinQdKy8Z1pyfdJZWVPms_Lb=aMxzQ@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, May 14, 2011 at 12:20 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> 2011/5/14 Darren Dale <report at bugs.python.org>:
>>
>> Darren Dale <dsdale24 at gmail.com> added the comment:
>>
>> Is there anything preventing this patch from being merged?
>
> I have to make time to think about the API a bit more.

Ok. Maybe you will come up with another alternative that hadn't
occurred to me. But I have given this issue quite a bit of thought,
considered several alternatives, and felt fortunate to find a solution
that preserves backwards compatibility, supports the property
decorator syntax, and meshes well with the existing syntax for
abstract methods. Perhaps, if you shared your concerns, I could help
address them and maybe save you some time.

Darrren

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat May 14 20:50:33 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 May 2011 18:50:33 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1305399033.28.0.945166541094.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It seems we're getting a bit off-topic for the issue title;  the discussion about cleaning up test_math (which I agree would be a good thing to do) should probably go into another issue.

On the issue itself, I'm -1 on making comparisons with float('nan') raise: I don't see that there's a real problem here that needs solving.  

Note that the current behaviour does *not* violate IEEE 754, since there's nothing anywhere in IEEE 754 that says that Python's < operation should raise for comparisons involving NaNs:  all that's said is that a conforming language should provide a number of comparison operations (without specifying how those operation should be spelt in the language in question), including both a < operation that's quiet (returning a false value for comparison with NaNs) and a < operation that signals on comparison with NaN.  There's nothing to indicate definitively which of these two operations '<' should bind to in a language.

It *is* true that C chooses to bind '<' to the signalling version, but that doesn't automatically mean that we should do the same in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 14 20:54:57 2011
From: report at bugs.python.org (Nir Aides)
Date: Sat, 14 May 2011 18:54:57 +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: <1305399297.63.0.0655124420366.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

I think that generally it is better to deadlock than corrupt data.

> 2) acquiring locks just before fork is probably one of the best way to
> deadlock (acquiring a lock we already hold, or acquiring a lock needed
> by another thread before it releases its own lock). Apart from adding
> dealock avoidance/recovery mechanisms - which would be far from
> trivial - I don't see how we could solve this, given that each library
> can use its own locks, not counting the user-created ones

a) We know the correct locking order in Python's std libraries so the problem there is kind of solved.

b) We can put the burden of other locks on application developers and since currently no one registers atfork handlers, there is no problem there yet.

> 4) Python locks differ from usual mutexes/semaphores in that they can
> be held for quite some time (for example while performing I/O). Thus,
> acquiring all the locks could take a long time, and users might get
> irritated if fork takes 2 seconds to complete.

We only need a prepare handler to acquire locks that protect data from corruption.

A lock synchronizing IO which is held for long periods may possibly be initialized in child without being acquired in a prepare handler; for example, a lock serializing logging messages.

In other cases or in general an atfork handler may reset or reinitialize a library without acquiring locks in a prepare handler.

> 5) Finally, there's a fundamental problem with this approach, because
> Python locks can be released by a thread other than the one that owns
> it.
> Imagine this happens:
>
> T1                         T2
>                          lock.acquire()
>                          (do something without releasing lock)
> fork()
> lock.release()
>
> This is perfectly valid with the current lock implementation (for
> example, it can be used to implement a rendez-vous point so that T2
> doesn't start processing before T1 forked worker processes, or
> whatever).
> But if T1 tries to acquire lock (held by T2) before fork, then it will
> deadlock, since it will never be release by T2.

I think we do not need to acquire rendezvous locks in a prepare handler.

> > Initializing locks in child after fork without acquiring them before the
> > fork may result in corrupted program state and so is probably not a good
> > idea.
>
> Yes, but in practise, I think that this shouldn't be too much of a
> problem. Also note that you can very well have the same type of
> problem with sections not protected explicitely by locks: for example,
> if you have a thread working exclusively on an object (maybe part of a
> threadpool), a fork can very well happen while the object is in an
> inconsistent state. Acquiring locks before fork won't help that.

I think a worker thread that works exclusively on an object does not create the problem:
a) If the fork thread eventually needs to read the object then you need synchronization.
b) If the worker thread eventually writes data into file or DB then that operation will be completed at the parent process.

To summarize I think we should take the atfork path. An atfork handler does not need to acquire all locks, but only those required by library logic, which the handler is aware of, and as a bonus it can be used to do all sort of stuff such as cleaning up, reinitializing a library, etc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat May 14 21:00:18 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 May 2011 19:00:18 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1305399618.97.0.395224752652.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Therefore making <, >, etc. raise on NaN while keeping the
> status quo for != and == would bring Python floats closer to
> compliance with IEEE 754.

Not so.  Either way, Python would be providing exactly 10 of the 22 required IEEE 754 comparison operations (see sections 5.6.1 and 5.11 of IEEE 754-2008 for details).  If we wanted to move closer to compliance with IEEE 754, we should be providing all 22 comparisons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 14 21:08:21 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 May 2011 19:08:21 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1305400101.13.0.429344945107.issue11949@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> On the issue itself, I'm -1 on making comparisons 
> with float('nan') raise: I don't see that there's
> a real problem here that needs solving.
>
> Note that the current behaviour does *not* violate IEEE 754, ...

I agree with Mark.  Am closing this feature request which is both ill-conceived and likely to cause more harm than good (possibly breaking code that currently does not fail).

> the discussion about cleaning up test_math 
> (which I agree would be a good thing to do) 
> should probably go into another issue.

I agree.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 14 22:28:13 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 May 2011 20:28:13 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1305404893.74.0.286298060695.issue11610@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat May 14 22:34:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 20:34:49 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <E1QLLY0-0007MC-CC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 850624632e9a by Nadeem Vawda in branch '3.1':
Issue #8650: Backport 64-bit safety fixes for compress() and decompress().
http://hg.python.org/cpython/rev/850624632e9a

New changeset 99a3ce22c1ff by Nadeem Vawda in branch '3.2':
Null merge (#8650): zlib.compress() and .decompress() are already 64-bit safe.
http://hg.python.org/cpython/rev/99a3ce22c1ff

New changeset dea5fcdc9ecd by Nadeem Vawda in branch 'default':
Null merge (#8650): zlib.compress() and .decompress() are already 64-bit safe.
http://hg.python.org/cpython/rev/dea5fcdc9ecd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Sat May 14 23:05:05 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 14 May 2011 21:05:05 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1305404893.74.0.286298060695.issue11610@psf.upfronthosting.co.za>
Message-ID: <BANLkTikTbK1AQy-1+veV=VTvvxk6yroAdA@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter).

Right, but I explained why the redundancy is necessary in order to
preserve backwards compatibility. If the abstractproperty constructor
were changed to tag methods it receives as abstract, it would be a
backwards-incompatible change in behavior with potential consequences
for consumers of abstractproperty.
abstractproperty.abstract(getter/setter/deleter) could be implemented,
but it still wouldn't change the fact that if a getter/setter is
intended to be abstract, it needs to be decorated with @abstractmethod
before being passed to the abstractproperty() constructor. This is
true today in <=python-3.2: its not mentioned in the documentation,
but the behavior exists all the same.

Properties are composite objects, their behavior is defined by it is
the setters/getters/deleters they receive. So its actually a very
conceptually clean solution to decorate a method with @abstractmethod,
and it fits really nicely with the rest of the abc module. Why does
abstractproperty need special abstract(setter/getter/deleter) methods,
when the existing methods combine with @abstractmethod in a clean way
to produce the exact same result? To save one line of code?

Darren

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat May 14 23:17:24 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 May 2011 21:17:24 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <BANLkTikTbK1AQy-1+veV=VTvvxk6yroAdA@mail.gmail.com>
Message-ID: <BANLkTin6a4Bak=ZTSO+_0jgjCfBx24Q2AQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/14 Darren Dale <report at bugs.python.org>:
>
> Darren Dale <dsdale24 at gmail.com> added the comment:
>
> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <benjamin at python.org> added the comment:
>>
>> I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter).
>
> Right, but I explained why the redundancy is necessary in order to
> preserve backwards compatibility. If the abstractproperty constructor
> were changed to tag methods it receives as abstract, it would be a
> backwards-incompatible change in behavior with potential consequences
> for consumers of abstractproperty.

I'm not suggesting that it tag methods it receives as abstract.
@getter/setter/deleter would still act the same.

> abstractproperty.abstract(getter/setter/deleter) could be implemented,
> but it still wouldn't change the fact that if a getter/setter is
> intended to be abstract, it needs to be decorated with @abstractmethod
> before being passed to the abstractproperty() constructor.

Why not? You could set the __abstractmethod__ attribute in abstractgetter().

> This is
> true today in <=python-3.2: its not mentioned in the documentation,
> but the behavior exists all the same.

>
> Properties are composite objects, their behavior is defined by it is
> the setters/getters/deleters they receive. So its actually a very
> conceptually clean solution to decorate a method with @abstractmethod,
> and it fits really nicely with the rest of the abc module. Why does
> abstractproperty need special abstract(setter/getter/deleter) methods,
> when the existing methods combine with @abstractmethod in a clean way
> to produce the exact same result? To save one line of code?

I find it produces a rather unfortunate ordering dependency for the
decorators which is hard to remember.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat May 14 23:48:15 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 14 May 2011 21:48:15 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <BANLkTin6a4Bak=ZTSO+_0jgjCfBx24Q2AQ@mail.gmail.com>
Message-ID: <BANLkTins=zipU_rshZW0_E2wnRnCcqxo3Q@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> 2011/5/14 Darren Dale <report at bugs.python.org>:
>>
>> Darren Dale <dsdale24 at gmail.com> added the comment:
>>
>> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
>> <report at bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <benjamin at python.org> added the comment:
>>>
>>> I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter).
>>
>> Right, but I explained why the redundancy is necessary in order to
>> preserve backwards compatibility. If the abstractproperty constructor
>> were changed to tag methods it receives as abstract, it would be a
>> backwards-incompatible change in behavior with potential consequences
>> for consumers of abstractproperty.
>
> I'm not suggesting that it tag methods it receives as abstract.
> @getter/setter/deleter would still act the same.

I wasn't talking about @getter/setter/deleter. I tried to be clear
that I was talking about the abstractproperty() constructor. It
doesn't currently tag the methods it receives as abstract, and to
change this would be a backward incompatible change. Therefore,
@abstractmethod should be used to tag methods as abstract before
passing them to the abstractproperty() constructor, and the abc
documentation should be changed to reflect this.

>> abstractproperty.abstract(getter/setter/deleter) could be implemented,
>> but it still wouldn't change the fact that if a getter/setter is
>> intended to be abstract, it needs to be decorated with @abstractmethod
>> before being passed to the abstractproperty() constructor.
>
> Why not? You could set the __abstractmethod__ attribute in abstractgetter().

I was not talking about decorating before passing @abstractgetter. I
was talking about decorating before passing to the abstractproperty()
constructor.

>> This is
>> true today in <=python-3.2: its not mentioned in the documentation,
>> but the behavior exists all the same.
>
>>
>> Properties are composite objects, their behavior is defined by it is
>> the setters/getters/deleters they receive. So its actually a very
>> conceptually clean solution to decorate a method with @abstractmethod,
>> and it fits really nicely with the rest of the abc module. Why does
>> abstractproperty need special abstract(setter/getter/deleter) methods,
>> when the existing methods combine with @abstractmethod in a clean way
>> to produce the exact same result? To save one line of code?
>
> I find it produces a rather unfortunate ordering dependency for the
> decorators which is hard to remember.

Why is it difficult to remember that you need to tag a method as
abstract before passing it to the property?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sat May 14 23:49:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 May 2011 21:49:39 +0000
Subject: [issue12078] re.sub() replaces only several matches
In-Reply-To: <1305385620.83.0.961543028277.issue12078@psf.upfronthosting.co.za>
Message-ID: <1305409779.91.0.40012568441.issue12078@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See #11957.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> re.sub confusion between count and flags args

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12078>
_______________________________________

From report at bugs.python.org  Sat May 14 23:55:08 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 May 2011 21:55:08 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <BANLkTins=zipU_rshZW0_E2wnRnCcqxo3Q@mail.gmail.com>
Message-ID: <BANLkTi=+2gqz8BzZ=RCpKVCRed1rNYkszA@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Okay: how about this. We retain the passing of @abstractmethod to
abstractpropert(), but @abstractgetter decorates the method for you.

2011/5/14 Darren Dale <report at bugs.python.org>:
>
> Darren Dale <dsdale24 at gmail.com> added the comment:
>
> On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <benjamin at python.org> added the comment:
>>
>> 2011/5/14 Darren Dale <report at bugs.python.org>:
>>>
>>> Darren Dale <dsdale24 at gmail.com> added the comment:
>>>
>>> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
>>> <report at bugs.python.org> wrote:
>>>>
>>>> Benjamin Peterson <benjamin at python.org> added the comment:
>>>>
>>>> I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter).
>>>
>>> Right, but I explained why the redundancy is necessary in order to
>>> preserve backwards compatibility. If the abstractproperty constructor
>>> were changed to tag methods it receives as abstract, it would be a
>>> backwards-incompatible change in behavior with potential consequences
>>> for consumers of abstractproperty.
>>
>> I'm not suggesting that it tag methods it receives as abstract.
>> @getter/setter/deleter would still act the same.
>
> I wasn't talking about @getter/setter/deleter. I tried to be clear
> that I was talking about the abstractproperty() constructor. It
> doesn't currently tag the methods it receives as abstract, and to
> change this would be a backward incompatible change. Therefore,
> @abstractmethod should be used to tag methods as abstract before
> passing them to the abstractproperty() constructor, and the abc
> documentation should be changed to reflect this.
>
>>> abstractproperty.abstract(getter/setter/deleter) could be implemented,
>>> but it still wouldn't change the fact that if a getter/setter is
>>> intended to be abstract, it needs to be decorated with @abstractmethod
>>> before being passed to the abstractproperty() constructor.
>>
>> Why not? You could set the __abstractmethod__ attribute in abstractgetter().
>
> I was not talking about decorating before passing @abstractgetter. I
> was talking about decorating before passing to the abstractproperty()
> constructor.
>
>>> This is
>>> true today in <=python-3.2: its not mentioned in the documentation,
>>> but the behavior exists all the same.
>>
>>>
>>> Properties are composite objects, their behavior is defined by it is
>>> the setters/getters/deleters they receive. So its actually a very
>>> conceptually clean solution to decorate a method with @abstractmethod,
>>> and it fits really nicely with the rest of the abc module. Why does
>>> abstractproperty need special abstract(setter/getter/deleter) methods,
>>> when the existing methods combine with @abstractmethod in a clean way
>>> to produce the exact same result? To save one line of code?
>>
>> I find it produces a rather unfortunate ordering dependency for the
>> decorators which is hard to remember.
>
> Why is it difficult to remember that you need to tag a method as
> abstract before passing it to the property?

I don't think the common case should be passing things to
abstractproperty(), rather using the decorator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun May 15 00:07:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 22:07:13 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <E1QLMzP-00075H-DW@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 536ec6206584 by Kurt B. Kaiser in branch '3.1':
Issue #6378: Further adjust idle.bat to start associated Python
http://hg.python.org/cpython/rev/536ec6206584

New changeset cd55c6960d86 by Kurt B. Kaiser in branch '3.2':
Merge from 3.1
http://hg.python.org/cpython/rev/cd55c6960d86

New changeset ec3e73a25d84 by Kurt B. Kaiser in branch 'default':
Merge from 3.2
http://hg.python.org/cpython/rev/ec3e73a25d84

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Sun May 15 00:13:01 2011
From: report at bugs.python.org (Andriy Rysin)
Date: Sat, 14 May 2011 22:13:01 +0000
Subject: [issue12078] re.sub() replaces only several matches
In-Reply-To: <1305385620.83.0.961543028277.issue12078@psf.upfronthosting.co.za>
Message-ID: <1305411181.38.0.480767187678.issue12078@psf.upfronthosting.co.za>


Andriy Rysin <arysin at gmail.com> added the comment:

Ahh, I guess I should have read the docs. But then looks like I am not the fist or only one so it's not as embarrassing. :)

I would support the proposal in #11957 to make re flags non-int object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12078>
_______________________________________

From report at bugs.python.org  Sun May 15 00:18:48 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 14 May 2011 22:18:48 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <BANLkTi=+2gqz8BzZ=RCpKVCRed1rNYkszA@mail.gmail.com>
Message-ID: <BANLkTimirZArCh8V8MYSDmBtOmmqaP6p7Q@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> Okay: how about this. We retain the passing of @abstractmethod to
> abstractpropert(), but @abstractgetter decorates the method for you.

That can work, although I would advise against it. I find it strange
that we would use @abstractmethod sometimes and not others. If that is
what it takes to get the patch accepted, so be it. But since I don't
understand the motivation behind this approach, I won't be the one to
document the special cases of when @abstractmethod is required and
when it is not.

> 2011/5/14 Darren Dale <report at bugs.python.org>:
>>
>> Darren Dale <dsdale24 at gmail.com> added the comment:
>>
>> On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson
>> <report at bugs.python.org> wrote:
>>>
>>> Benjamin Peterson <benjamin at python.org> added the comment:
>>>
>>> 2011/5/14 Darren Dale <report at bugs.python.org>:
>>>>
>>>> Darren Dale <dsdale24 at gmail.com> added the comment:
>>>>
>>>> On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson
>>>> <report at bugs.python.org> wrote:
>>>>>
>>>>> Benjamin Peterson <benjamin at python.org> added the comment:
>>>>>
>>>>> I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter).
>>>>
>>>> Right, but I explained why the redundancy is necessary in order to
>>>> preserve backwards compatibility. If the abstractproperty constructor
>>>> were changed to tag methods it receives as abstract, it would be a
>>>> backwards-incompatible change in behavior with potential consequences
>>>> for consumers of abstractproperty.
>>>
>>> I'm not suggesting that it tag methods it receives as abstract.
>>> @getter/setter/deleter would still act the same.
>>
>> I wasn't talking about @getter/setter/deleter. I tried to be clear
>> that I was talking about the abstractproperty() constructor. It
>> doesn't currently tag the methods it receives as abstract, and to
>> change this would be a backward incompatible change. Therefore,
>> @abstractmethod should be used to tag methods as abstract before
>> passing them to the abstractproperty() constructor, and the abc
>> documentation should be changed to reflect this.
>>
>>>> abstractproperty.abstract(getter/setter/deleter) could be implemented,
>>>> but it still wouldn't change the fact that if a getter/setter is
>>>> intended to be abstract, it needs to be decorated with @abstractmethod
>>>> before being passed to the abstractproperty() constructor.
>>>
>>> Why not? You could set the __abstractmethod__ attribute in abstractgetter().
>>
>> I was not talking about decorating before passing @abstractgetter. I
>> was talking about decorating before passing to the abstractproperty()
>> constructor.
>>
>>>> This is
>>>> true today in <=python-3.2: its not mentioned in the documentation,
>>>> but the behavior exists all the same.
>>>
>>>>
>>>> Properties are composite objects, their behavior is defined by it is
>>>> the setters/getters/deleters they receive. So its actually a very
>>>> conceptually clean solution to decorate a method with @abstractmethod,
>>>> and it fits really nicely with the rest of the abc module. Why does
>>>> abstractproperty need special abstract(setter/getter/deleter) methods,
>>>> when the existing methods combine with @abstractmethod in a clean way
>>>> to produce the exact same result? To save one line of code?
>>>
>>> I find it produces a rather unfortunate ordering dependency for the
>>> decorators which is hard to remember.
>>
>> Why is it difficult to remember that you need to tag a method as
>> abstract before passing it to the property?
>
> I don't think the common case should be passing things to
> abstractproperty(), rather using the decorator.

It definitely is a common case, and always will be. You can't begin
using abstractproperty.abstract(getter/setter/deleter) until you have
an abstract property, which requires passing a (potentially abstract)
method to the constructor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun May 15 00:24:12 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 May 2011 22:24:12 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <BANLkTimirZArCh8V8MYSDmBtOmmqaP6p7Q@mail.gmail.com>
Message-ID: <BANLkTimjxvpagN8T6577riE90j+VncTL3A@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/14 Darren Dale <report at bugs.python.org>:
>
> Darren Dale <dsdale24 at gmail.com> added the comment:
>
> On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <benjamin at python.org> added the comment:
>>
>> Okay: how about this. We retain the passing of @abstractmethod to
>> abstractpropert(), but @abstractgetter decorates the method for you.
>
> That can work, although I would advise against it. I find it strange
> that we would use @abstractmethod sometimes and not others. If that is
> what it takes to get the patch accepted, so be it. But since I don't
> understand the motivation behind this approach, I won't be the one to
> document the special cases of when @abstractmethod is required and
> when it is not.

It would just be a convenience.

> It definitely is a common case, and always will be. You can't begin
> using abstractproperty.abstract(getter/setter/deleter) until you have
> an abstract property, which requires passing a (potentially abstract)
> method to the constructor.

What about

@abstractproperty
def something(): pass

@abstractproperty.setter
def set(): pass

@abstractproperty.deleter
def delete: pass

requires you to pass a method (explicitly) to a constructor?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun May 15 00:24:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 22:24:56 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <E1QLNGY-00084E-FY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0b5211d19a14 by Nadeem Vawda in branch '3.1':
Issue #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/0b5211d19a14

New changeset 3ff862d05d18 by Nadeem Vawda in branch '3.2':
Merge: #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/3ff862d05d18

New changeset f86a22b6ab58 by Nadeem Vawda in branch 'default':
Merge: #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/f86a22b6ab58

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Sun May 15 00:30:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 May 2011 22:30:36 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1305412236.3.0.412426848568.issue11957@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/issue11957>
_______________________________________

From report at bugs.python.org  Sun May 15 00:36:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 May 2011 22:36:22 +0000
Subject: [issue12059] hashlib does not handle missing hash functions correctly
In-Reply-To: <1305140359.29.0.351905173932.issue12059@psf.upfronthosting.co.za>
Message-ID: <E1QLNRc-0000PO-Q2@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 572fbd9ca28f by Gregory P. Smith in branch '2.7':
Fixes Issue #12059: Properly handle missing hash functions even when
http://hg.python.org/cpython/rev/572fbd9ca28f

New changeset ad9249f35914 by Gregory P. Smith in branch '3.2':
Fixes Issue #12059: Properly handle missing hash functions even when
http://hg.python.org/cpython/rev/ad9249f35914

New changeset 298888fd46b0 by Gregory P. Smith in branch 'default':
Fixes Issue #12059: Properly handle missing hash functions even when
http://hg.python.org/cpython/rev/298888fd46b0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12059>
_______________________________________

From report at bugs.python.org  Sun May 15 00:36:35 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 14 May 2011 22:36:35 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <BANLkTimjxvpagN8T6577riE90j+VncTL3A@mail.gmail.com>
Message-ID: <BANLkTikznqPySO+Z3NyXBPg+4bVX_t6LVQ@mail.gmail.com>


Darren Dale <dsdale24 at gmail.com> added the comment:

On Sat, May 14, 2011 at 6:24 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> 2011/5/14 Darren Dale <report at bugs.python.org>:
>>
>> Darren Dale <dsdale24 at gmail.com> added the comment:
>>
>> It definitely is a common case, and always will be. You can't begin
>> using abstractproperty.abstract(getter/setter/deleter) until you have
>> an abstract property, which requires passing a (potentially abstract)
>> method to the constructor.
>
> What about
>
> @abstractproperty
> def something(): pass
>
> @abstractproperty.setter
> def set(): pass
>
> @abstractproperty.deleter
> def delete: pass
>
> requires you to pass a method (explicitly) to a constructor?

@abstractproperty
def something(): pass

takes the "something" function and passes it to the abstractproperty()
constructor.

It doesn't appear that you are familiar with how the decorator syntax
works for properties. Here is how your example should probably look:

@abstractproperty
def something(): pass

@something.setter
def something(): pass

@something.deleter
def something(): pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun May 15 00:37:13 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 14 May 2011 22:37:13 +0000
Subject: [issue12059] hashlib does not handle missing hash functions correctly
In-Reply-To: <1305140359.29.0.351905173932.issue12059@psf.upfronthosting.co.za>
Message-ID: <1305412633.65.0.432136449584.issue12059@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12059>
_______________________________________

From report at bugs.python.org  Sun May 15 00:49:06 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 14 May 2011 22:49:06 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305413346.36.0.506947175138.issue12060@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

if you used the pipe approach you'd need to deal with the case of the write blocking (or failing if nonblocking) when the pipe buffer is full.  also you'd need to block signals around a fork and reinitialize the pipe in the child before reenabling signals.

i think all of this is overkill.  as said, this isn't a real problem.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Sun May 15 01:09:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 14 May 2011 23:09:20 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1305414560.46.0.908005926709.issue8650@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Fixed in 3.1, 3.2 and 3.3.

2.7 no longer has this problem -- the fix for issue8651 ensures that the
functions cannot receive inputs large enough to be problematic (since we
don't define PY_SSIZE_T_CLEAN).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2, Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Sun May 15 01:14:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 May 2011 23:14:33 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1305399297.63.0.0655124420366.issue6721@psf.upfronthosting.co.za>
Message-ID: <BANLkTinffJxUVS1KZeXDgrhEVKBcOyBMJA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> a) We know the correct locking order in Python's std libraries so the problem there is kind of solved.

I think that you're greatly under-estimating the complexity of lock ordering.
If we were just implementing a malloc implementation protected with a
single mutex, then yes, it would be simple.
But here, you have multiple libraries with each their own locks, locks
at the I/O layer, in the socket module (some name resolution libraries
are not thread-safe), and in many other places. And all those
interact.
For example, buffered I/O objects each have their own lock (Antoine,
correct me if I'm wrong).
It's a common cause of deadlock.
Now imagine I have a thread that logs information to a bz2 stream, so
that it's compressed on-the-fly. Sounds reasonable, no?
Well, the lock hierarchy is:

buffered stream lock
bz2-level lock
logging object I/O lock

Do you still think that getting the locking order right is easy?

Another example, with I/O locks (and if you're concerned with data
corruption, those are definitely the one you would want to handle with
atfork):
I have a thread blocking on a write (maybe the output pipe is full,
maybe it's a NFS file system and the server takes a long time to
respond, etc. Or maybe it's just waiting for someone to type something
on stdin.).
Another thread forks.
The atfork-handler will try to acquire the buffered I/O object's lock:
it won't succeed until the other threads finally manages to
write/read. It could take seconds, or forever.
And there are many other things that could go wrong, because
contrarily to a standalone and self-contained library, Python is made
of several components, at different layers, that can call each other
in an arbitrary order. Also, some locks can be held for arbitrarily
long.

That's why I still think that this can be fully handled by atfork handlers.

But don't get me wrong: like you, I think that we should definitely
have an atfork mechanism. I just think it won't be able to solve all
the issues, and that I can also bring its own set of troubles.

Concerning the risk of corruption (invariant broken), you're right.
But resetting the locks is the approach currently in use for the
threading module, and it seems to work reasonably well there.

Finally, I'd just like to insist on a point:
In a multi-threaded program, between fork and exec, the code must be
async-safe. This means that in theory, you can't call
pthread_mutex_release/pthread_mutex_destroy, fwrite, malloc, etc.
Period.
This means that in theory, we shouldn't be running Python code at all!
So if we really wanted to be safe, the only solution would be to
forbid fork() in a multi-threaded program.
Since it's not really a reasonable option, and that the underlying
platform (POSIX) doesn't allow to be safe either, I guess that the
only choice left is to provide a bet-try implementation, knowing
perfectly that there will always be some corner cases that can't be
handled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun May 15 01:19:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 May 2011 23:19:21 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305415161.68.0.57058760488.issue12060@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> if you used the pipe approach you'd need to deal with the case of the
> write blocking (or failing if nonblocking) when the pipe buffer is full.

Well, a pipe is 64K on Linux (4K on older kernels). Given that each signal received consumes one byte, I'd be pretty surprised if we managed to fill the pipe before Py_CheckSignals() gets called.

> i think all of this is overkill.  as said, this isn't a real problem.

Definitely. Do you think this can be closed as "wont fix" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Sun May 15 01:26:30 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 14 May 2011 23:26:30 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305415590.82.0.252811654554.issue12060@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

if someone comes up with a situation where this is a real problem, feel free to reopen it.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Sun May 15 01:42:33 2011
From: report at bugs.python.org (Darren Dale)
Date: Sat, 14 May 2011 23:42:33 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1305416553.86.0.773099594914.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

It just occurred to me, there is a potential problem with abstractproperty and the decorator syntax in my patch:

class Foo:

    @abstractproperty
    def p(self): pass
    # p is abstract, but has no abstract methods

    @p.setter
    def p(self, val): pass
    # p has no abstract properties, at this point it becomes an instance
    # of property, not abstractproperty

    @p.deleter
    @abstractmethod
    def p(self): pass
    # the deleter was tagged as abstract, but p was already a
    # regular property. There is no way to turn a regular
    # property into an abstractproperty, so the abstractedness
    # of the deleter is not respected.

Really, the ideal approach is the original one: provide the builtin property with an __isabstractmethod__ attribute, which is set to True if the property has any abstract methods, and False otherwise. (My C is probably too weak to modify the property builtin on my own).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun May 15 01:44:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 May 2011 23:44:27 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1305416667.29.0.0874239102849.issue11610@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Sun May 15 06:39:35 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 15 May 2011 04:39:35 +0000
Subject: [issue12038] assertEqual doesn't display newline differences quite
	well
In-Reply-To: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>
Message-ID: <1305434375.98.0.499967582919.issue12038@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

We should ensure that the first differing character in the string is always included in what is displayed as a diff.  if we're going to shorten a string we should elide something that matches.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12038>
_______________________________________

From report at bugs.python.org  Sun May 15 07:13:09 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 15 May 2011 05:13:09 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1305436389.19.0.867066186348.issue1615158@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Adding this to the posix module would enforce linking with lcap and lattr always. The development headers for these are not installed by default on some distributions.

I think it would be better if they are added to a separate module (especially since all the functions are prefixed with cap_, it is like they are in their own namespace) which means that the module is optional for people that don't have/want to build the functionality.

What are your thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Sun May 15 08:37:36 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2011 06:37:36 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1305441456.94.0.802348323995.issue11802@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

-1 on backporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sun May 15 08:51:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2011 06:51:42 +0000
Subject: [issue6498] Py_Main() does not return on SystemExit
In-Reply-To: <1247787023.18.0.165575901629.issue6498@psf.upfronthosting.co.za>
Message-ID: <E1QLVAy-00033o-En@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0311f62714f7 by Georg Brandl in branch '3.1':
Closes #6498: fix several misspellings of "SystemExit" as "SystemError".
http://hg.python.org/cpython/rev/0311f62714f7

New changeset 7089afd69a1a by Georg Brandl in branch '3.2':
Merge #6498 fix from 3.1.
http://hg.python.org/cpython/rev/7089afd69a1a

New changeset 94e3c44b0662 by Georg Brandl in branch 'default':
Merge #6498 fix from 3.2.
http://hg.python.org/cpython/rev/94e3c44b0662

New changeset 97a75fccd7c8 by Georg Brandl in branch '2.7':
Port #6498 fix: fix several misspellings of "SystemExit" as "SystemError".
http://hg.python.org/cpython/rev/97a75fccd7c8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6498>
_______________________________________

From report at bugs.python.org  Sun May 15 09:27:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2011 07:27:05 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <E1QLVjD-0004y4-It@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c2515cb23d9b by Gregory P. Smith in branch 'default':
Issue #1746656: Add if_nameindex, if_nametoindex, if_indextoname
http://hg.python.org/cpython/rev/c2515cb23d9b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 09:29:33 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 15 May 2011 07:29:33 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305444573.79.0.235844526388.issue1746656@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I added these with conditional compilation via autoconf for use on posix systems.  These methods are not IPv6 specific.

Anyone who wants to see them supported on windows will need to add whatever conditional compilation magic is required to enable that on appropriate builds.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 09:41:58 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 15 May 2011 07:41:58 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1305445318.8.0.529978469122.issue10756@psf.upfronthosting.co.za>


kai zhu <kaizhu at ugcs.caltech.edu> added the comment:

should this bug b closed? it seems fixed in python3.2 for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Sun May 15 09:50:06 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 May 2011 07:50:06 +0000
Subject: [issue12079] decimal.py: TypeError precedence in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hi, I think that TypeError should take precedence over InvalidOperation
in these two cases:

>>> Decimal('Infinity').fma(Decimal('0'), (3.91224318126786e+19+0j))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/decimal.py", line 1879, in fma
    'INF * 0 in fma')
  File "/usr/local/lib/python3.2/decimal.py", line 3926, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: INF * 0 in fma
>>> 


>>> Decimal('1').fma(Decimal('snan'), 1.2222222222)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.2/decimal.py", line 1871, in fma
    return context._raise_error(InvalidOperation, 'sNaN', other)
  File "/usr/local/lib/python3.2/decimal.py", line 3926, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: sNaN
>>>

----------
components: Library (Lib)
messages: 136014
nosy: mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: decimal.py: TypeError precedence in fma()
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12079>
_______________________________________

From report at bugs.python.org  Sun May 15 09:53:36 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2011 07:53:36 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1305446016.79.0.901348756655.issue10756@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, Victor still wanted to backport it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Sun May 15 09:56:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2011 07:56:03 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305446163.11.0.267783637449.issue1746656@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset c2515cb23d9b by Gregory P. Smith in branch 'default':
> Issue #1746656: Add if_nameindex, if_nametoindex, if_indextoname

The _socket module doesn't compile on OpenIndiana anymore:
http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1207/steps/test/logs/stdio

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 09:59:13 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 May 2011 07:59:13 +0000
Subject: [issue12079] decimal.py: TypeError precedence in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <1305446353.66.0.605610097795.issue12079@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, I agree.  Do you have a patch?  I guess the only mildly tricky part here is making sure that the patch doesn't cause fma(2, 3, snan) (for example) to raise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12079>
_______________________________________

From report at bugs.python.org  Sun May 15 10:01:43 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 May 2011 08:01:43 +0000
Subject: [issue12079] decimal.py: TypeError precedence in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <1305446503.73.0.640790683352.issue12079@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> cause fma(2, 3, snan) ...

Gah!  That was nonsense.  Please ignore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12079>
_______________________________________

From report at bugs.python.org  Sun May 15 10:02:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2011 08:02:28 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305446548.71.0.912807280429.issue1746656@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The _socket module doesn't compile on OpenIndiana anymore

Same problem of FreeBSD 8.2:
http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/291/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 10:14:42 2011
From: report at bugs.python.org (kai zhu)
Date: Sun, 15 May 2011 08:14:42 +0000
Subject: [issue12075] python3.2 memory leak when setting integer key in
	dictionary
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1305447282.94.0.296695128346.issue12075@psf.upfronthosting.co.za>


kai zhu <kaizhu at ugcs.caltech.edu> added the comment:

explicit gc.collect() doesn't seem to fix the leak in my application.
my current fix is to not re-instantiate the class attribute (which cost ~7mb) during reload & instead reference one created earlier.

i haven't pinpointed y, but i suspect its a corner case, which would rarely occur in general usage.  my class also inherits from subprocess.Popen, which has a __del__ method, which might interfere w/ collection (although gc.garbage says otherwise ;).

the reason i reload is that the script gets modified frequently, which the auto-build system will detect & reload.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12075>
_______________________________________

From report at bugs.python.org  Sun May 15 10:28:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2011 08:28:00 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <E1QLWgA-0008Gm-E0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 945ca78c38b1 by Victor Stinner in branch '3.1':
Issue #12060: Use sig_atomic_t type and volatile keyword in the signal module.
http://hg.python.org/cpython/rev/945ca78c38b1

New changeset b74999f561ca by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12060: Use sig_atomic_t type and volatile keyword in the
http://hg.python.org/cpython/rev/b74999f561ca

New changeset 1aa48391da30 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12060: Use sig_atomic_t type and volatile keyword in the
http://hg.python.org/cpython/rev/1aa48391da30

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Sun May 15 10:28:22 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 May 2011 08:28:22 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I found another performance issue in _power_exact:

>>> Decimal(4) ** Decimal("-1.2e-999999999")
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/stefan/pydev/cpython/Lib/decimal.py", line 2343, in __pow__
    ans = self._power_exact(other, context.prec + 1)
  File "/home/stefan/pydev/cpython/Lib/decimal.py", line 2098, in _power_exact
    ten_pow = 10**-ye
KeyboardInterrupt



This one is in the power operation in line 2098. There are several
other places where huge integer powers are calculated if 'ye' is
sufficiently large.

----------
components: Library (Lib)
messages: 136022
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: decimal.py: performance in _power_exact
type: performance
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12080>
_______________________________________

From report at bugs.python.org  Sun May 15 10:28:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2011 08:28:43 +0000
Subject: [issue12060] Python doesn't support real time signals
In-Reply-To: <1305151062.27.0.134082795886.issue12060@psf.upfronthosting.co.za>
Message-ID: <1305448123.99.0.69013519356.issue12060@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> if someone comes up with a situation where this is a real problem,
> feel free to reopen it.

Ok I agree, no problem. But I commited at least Charles's patch ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12060>
_______________________________________

From report at bugs.python.org  Sun May 15 10:29:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 May 2011 08:29:43 +0000
Subject: [issue12079] decimal.py: TypeError precedence in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <1305448183.68.0.535507435421.issue12079@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Ok, I'll write a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12079>
_______________________________________

From report at bugs.python.org  Sun May 15 11:53:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 15 May 2011 09:53:36 +0000
Subject: [issue11963] Remove human verification from test suite (test_parser
	and test_subprocess)
In-Reply-To: <1304178205.97.0.319156485187.issue11963@psf.upfronthosting.co.za>
Message-ID: <1305453216.51.0.659676613709.issue11963@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I had a shot at test_subprocess but it?s harder than test_parser.  The method that outputs to stdout tests the behavior of Popen(..., stdout=None).  Putting another layer of indirection with script_helper could obfuscate it to the point of making it unreadable (what stdout are we talking about?  It?s a subprocess in a subprocess in a test).  I?ll try to do it in a few weeks but will not commit it without review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11963>
_______________________________________

From report at bugs.python.org  Sun May 15 11:59:27 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 15 May 2011 09:59:27 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305453567.44.0.398932003463.issue1746656@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Also failing to compile on OS X:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/1385/steps/test/logs/stdio

The problem seems to be that <net/if.h> is not being included on these
non-Linux systems. Looking at Modules/socketmodule.h reveals that its
inclusion is conditional on HAVE_NETPACKET_PACKET_H:

    #ifdef HAVE_NETPACKET_PACKET_H
    # include <sys/ioctl.h>
    # include <net/if.h>
    # include <netpacket/packet.h>
    #endif

Changing it to something like this should solve the problem:

    #ifdef HAVE_NET_IF_H
    # include <net/if.h>
    #endif

    #ifdef HAVE_NETPACKET_PACKET_H
    # include <sys/ioctl.h>
    # include <netpacket/packet.h>
    #endif

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 13:28:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2011 11:28:10 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <E1QLZUT-0001tn-RT@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 434dfe42fde1 by Nadeem Vawda in branch 'default':
Fix _socket compilation failures on non-Linux buildbots (cf. issue #1746656).
http://hg.python.org/cpython/rev/434dfe42fde1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 14:26:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 15 May 2011 12:26:36 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305462396.24.0.984431246048.issue1746656@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The OpenIndiana bots are now green, but the BSD and OS X bots are still
failing. It seems that on those systems, <net/if.h> depends on <sys/types.h> and maybe some other headers, so the current configure
script detects it as "present but not usable".

I'm currently setting up a FreeBSD VM so I can poke around and figure out
what the missing dependencies are.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 14:31:08 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 15 May 2011 12:31:08 +0000
Subject: [issue11802] filecmp.cmp needs a documented way to clear cache
In-Reply-To: <1302233844.4.0.517722747064.issue11802@psf.upfronthosting.co.za>
Message-ID: <1305462668.14.0.490061044998.issue11802@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

OK. I'll try to put together something cleaner just for 3.3, then.

----------
assignee:  -> nadeem.vawda
stage: patch review -> needs patch
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11802>
_______________________________________

From report at bugs.python.org  Sun May 15 16:26:38 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 15 May 2011 14: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: <1305469598.25.0.460670616041.issue10639@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Re msg125818, I agree that the mixed EOLs is also a potential problem, though the proposed solution behaves better than the status quo, where the EOLs get converted without warning.

It would be desirable for the patch to be more robust in that situation (providing a useful error message about why it fails). What might even be better is to retain newlines even if they're mixed. I'll explore a cross-platform technique to consistently retain newlines as encountered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10639>
_______________________________________

From report at bugs.python.org  Sun May 15 17:07:56 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 May 2011 15:07:56 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1305472076.9.0.133498060794.issue1615158@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

posix module has many optional functions, which are available only on some systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Sun May 15 17:14:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2011 15:14:11 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <E1QLd1G-0002DR-A9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9874f213edb2 by Ronald Oussoren in branch '2.7':
Issue #9516: avoid errors in sysconfig when MACOSX_DEPLOYMENT_TARGET is set in shell.
http://hg.python.org/cpython/rev/9874f213edb2

New changeset 5b108229a978 by Ronald Oussoren in branch '3.2':
Issue #9516: avoid errors in sysconfig when MACOSX_DEPLOYMENT_TARGET is set in shell.
http://hg.python.org/cpython/rev/5b108229a978

New changeset 978016199be8 by Ronald Oussoren in branch '2.7':
NEWS entry for fix of issue #9516
http://hg.python.org/cpython/rev/978016199be8

New changeset 25040a6a68e9 by Ronald Oussoren in branch '3.2':
NEWS entry for fix of issue #9516
http://hg.python.org/cpython/rev/25040a6a68e9

New changeset 412d5f2c995f by Ronald Oussoren in branch 'default':
(merge from 3.2) Issue #9516: avoid errors in sysconfig when MACOSX_DEPLOYMENT_TARGET is set in shell.
http://hg.python.org/cpython/rev/412d5f2c995f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sun May 15 17:15:27 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 15 May 2011 15:15:27 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1305472527.12.0.998004643733.issue9516@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied the patches to 3.3, 3.2 and 2.7

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Sun May 15 17:37:06 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 15 May 2011 15:37:06 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

I believe the bugs which the patched version of libffi used have been fixed in recent versions. We should stop distributing an old version.

----------
components: ctypes
messages: 136034
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Remove distributed copy of libffi
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12081>
_______________________________________

From report at bugs.python.org  Sun May 15 17:40:23 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 15 May 2011 15:40:23 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305474023.49.0.718914581878.issue12081@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/issue12081>
_______________________________________

From report at bugs.python.org  Sun May 15 17:46:13 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 15 May 2011 15:46:13 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305474373.46.0.70699703768.issue12081@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/issue12081>
_______________________________________

From report at bugs.python.org  Sun May 15 17:47:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2011 15:47:54 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305474474.11.0.784435715232.issue11614@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Sun May 15 17:59:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2011 15:59:27 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305475167.97.0.764157586214.issue12081@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sounds reasonable.  How will this work on Windows?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12081>
_______________________________________

From report at bugs.python.org  Sun May 15 18:52:23 2011
From: report at bugs.python.org (Tim Lyons)
Date: Sun, 15 May 2011 16:52:23 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1305478343.75.0.655370473066.issue10466@psf.upfronthosting.co.za>


Tim Lyons <guy.linton at gmail.com> added the comment:

Surely the user of getlocale as the right to expect that the same thing (i.e. ISO language codes) would be returned on all platforms. I am looking at some code that provides special purpose date handling routines. The appropriate routine is selected by a language code (for the locale category LC_TIME as it happens) like fr_FR. In order  to get this to work on different platforms, you have to test whether it is windows, and if so use getdefaultlocale, while for other platforms, you use getlocale in order to return similar language codes. This code would actually be wrong if the application were to change the locale inside the application, because on other platforms the change would have an effect, while on windows, it would be ignored! [I am running on Mac OS X as it happens, not Linux or Windows].
 
So, don?t say that getdefaultloale is not useful, it is the one that is needed on Windows!
 
Note this is not a problem with the encoding ? some of the discussion and many of the related bugs are concerned with the encoding.
 
Also note Marc-Andre pointing out in http://mail.python.org/pipermail/python-bugs-list/2004-December/026667.html that ?getdefaultlocale() mimics the lookup mechanism of setlocale(LC_ALL, "")?. I recognise that he is talking about the lookup mechanism rather than the results, but it seems to suggest that the results might be similar (if you do the same lookup you would get the same result). But ?getdefaultlocale returns something that setlocale cannot consume on Windows?!

I recognise that it would be difficult to decide to code locale on python so that windows returns something that is not the same as the native call, but it does seem to me that python locale should translate the Windows language codes so that they are the same as are returned on all the other platforms (i.e. ISO codes etc).

----------
nosy: +guy.linton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Sun May 15 18:54:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 15 May 2011 16:54:07 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <1304976994.14.0.502934856435.issue11877@psf.upfronthosting.co.za>
Message-ID: <20110515165052.GA21350@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> Finally, depending on the workload, it could have a significant
> performance impact.

Oh yes (first replaces os.fsync() with an in-python wrapper):

18:12 ~/tmp $ ll mail
ls: mail: No such file or directory
18:12 ~/tmp $ ll X-MAIL
312 -rw-r-----  1 steffen  staff  315963 15 May 17:49   X-MAIL
18:12 ~/tmp $ time s-postman.py --folder=~/tmp/mail --dispatch=X-MAIL
Dispatched 37 tickets to 4 targets.

real	0m4.638s
user	0m0.974s
sys	0m0.160s
18:13 ~/tmp $ rm -rf mail
18:13 ~/tmp $ time s-postman.py --folder=~/tmp/mail --dispatch=X-MAIL
Dispatched 37 tickets to 4 targets.

real	0m1.228s
user	0m0.976s
sys	0m0.122s

(I'm using the first one.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sun May 15 19:02:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2011 17:02:40 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <E1QLeiF-00028d-3p@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 461e37a60187 by Victor Stinner in branch '3.1':
Issue #10756: atexit normalizes the exception before displaying it. Patch by
http://hg.python.org/cpython/rev/461e37a60187

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Sun May 15 19:03:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 15 May 2011 17:03:50 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <BANLkTinffJxUVS1KZeXDgrhEVKBcOyBMJA@mail.gmail.com>
Message-ID: <20110515170342.GB21350@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@ Charles-Fran?ois Natali wrote (2011-05-15 01:14+0200):
> So if we really wanted to be safe, the only solution would be to
> forbid fork() in a multi-threaded program.
> Since it's not really a reasonable option

But now - why this?  The only really acceptable thing if you have
control about what you are doing is the following:

class SMP::Process
    /*!
    * \brief Daemonize process.
    *[.]
    * \note
    * The implementation of this function is not trivial.
    * To avoid portability no-goes and other such problems,
    * you may \e not call this function after you have initialized
    * Thread::enableSMP(),
    * nor may there (have) be(en) Child objects,
    * nor may you have used an EventLoop!
    * I.e., the process has to be a single threaded, "synchronous" one.
    * [.]
    */
    pub static si32 daemonize(ui32 _daemon_flags=df_default);

namespace SMP::POSIX
    /*!
    * \brief \fn fork(2).
    *[.]
    * Be aware that this passes by all \SMP and Child related code,
    * i.e., this simply \e is the system-call.
    * Signal::resetAllSignalStates() and Child::killAll() are thus if
    * particular interest; thread handling is still entirely up to you.
    */
    pub static sir fork(void);

Which kind of programs cannot be written with this restriction?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun May 15 19:06:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2011 17:06:35 +0000
Subject: [issue10756] Error in atexit._run_exitfuncs [...] Exception expected
	for value, str found
In-Reply-To: <1293004716.16.0.718567163143.issue10756@psf.upfronthosting.co.za>
Message-ID: <1305479195.21.0.567000875839.issue10756@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I forgot the issue. I backported the fix to Python 3.1. Python 2.7 doesn't have the bug.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10756>
_______________________________________

From report at bugs.python.org  Sun May 15 19:34:12 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 May 2011 17:34:12 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305480852.53.0.910837296105.issue12081@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/issue12081>
_______________________________________

From report at bugs.python.org  Sun May 15 19:46:56 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 15 May 2011 17:46:56 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
In-Reply-To: <1305462396.24.0.984431246048.issue1746656@psf.upfronthosting.co.za>
Message-ID: <BANLkTikDacJ+CTHj13B-OP4owkschQ9Zog@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks i'll take a look at OS X here.  obviously i did development and
testing on linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 20:19:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 15 May 2011 18:19:20 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305483560.81.0.195324586349.issue1746656@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

OK, that's great. It'll be another couple of hours before I can do
anything from the FreeBSD side; I'm still waiting for the ISO to finish
downloading :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 20:30:00 2011
From: report at bugs.python.org (Jiri Horky)
Date: Sun, 15 May 2011 18:30:00 +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: <1305484200.4.0.764261304288.issue11898@psf.upfronthosting.co.za>


Jiri Horky <jiri.horky at gmail.com> added the comment:

I have the same problem as the original submitter.

The reason it previously worked for you was probably because you didn't utilize a "right" unicode string in the urllib2.request. The following code will raise the exception (I enclose the data file for completeness, but it fails with basically any binary data).

It works fine with Python 2.6.6, but fails with Python 2.7.1.

{{{
import urllib2

f = open("data", "r")
mydata = f.read()
f.close()

#this fails
url=unicode('http://localhost/test')

#this works
#url=str('http://localhost/test')

#this also works 
#url=unicode('http://localhost')

req = urllib2.Request(url, data=mydata)
urllib2.urlopen(req)
}}}

----------
nosy: +Jiri.Horky
Added file: http://bugs.python.org/file22004/data

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Sun May 15 20:37:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 May 2011 18:37:22 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1305484642.91.0.803521291406.issue12080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report;  I'll try to find some time to look at this.

This isn't the first time that I've thought that it might be better just to abandon the aim of getting correctly-rounded results for pow.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12080>
_______________________________________

From report at bugs.python.org  Sun May 15 20:51:27 2011
From: report at bugs.python.org (Nir Aides)
Date: Sun, 15 May 2011 18:51:27 +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: <1305485487.42.0.300111043565.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Is it possible the following issue is related to this one?
http://bugs.python.org/issue10037 - "multiprocessing.pool processes started by worker handler stops working"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun May 15 20:57:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 May 2011 18:57:54 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1305485874.78.0.502147321412.issue12080@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12080>
_______________________________________

From report at bugs.python.org  Sun May 15 21:18:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2011 19:18:38 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <E1QLgpo-0002ty-PZ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b6aafb20e5f5 by Gregory P. Smith in branch 'default':
issue #1746656: Fix for OS X. configure and #include changes so that the socket
http://hg.python.org/cpython/rev/b6aafb20e5f5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Sun May 15 21:34:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 15 May 2011 19:34:38 +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: <1305488078.19.0.48932321315.issue6721@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file21991/reinit_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun May 15 21:39:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 15 May 2011 19:39: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: <1305488396.46.0.602295464999.issue6721@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Is it possible the following issue is related to this one?

It's hard to tell, the original report is rather vague.
But the comment about the usage of the maxtasksperchild argument reminds me of issue #10332 "Multiprocessing maxtasksperchild results in hang": basically, there's a race window in the Pool shutdown code where worker threads having completed their work can exit without being replaced.
So the connection with the current issue does not strike me, but you never know (that's the problem with those nasty race conditions ;-).

Concerning this issue, here's an updated patch.
I removed calls to pthread_mutex_destroy/pthread_condition_destroy/sem_destroy from the reinit functions: the reason is that I experienced a deadlock in test_concurrent_futures with the emulated semaphore code on Linux/NPTL inside pthread_condition_destroy: the new version strictly mimics what's done in glibc's malloc, and just calls pthrad_mutex_init and friends. It's safe, and shouldn't leak resources (and even if it does, it's way better than a deadlock).
I also placed the note on the interaction between locks and fork() at the top of Python/thread_pthread.h.

----------
Added file: http://bugs.python.org/file22005/reinit_locks.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sun May 15 22:11:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 15 May 2011 20:11:29 +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: <1305490289.16.0.924530468568.issue11877@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

(I'm not sure Rietveld sent the message so I post it here, sorry in case of duplicate).

Steffen, I've made a quick review of your patch, in case you're interested.
I think that this functionality can be really useful to some people, and it'd be
nice if your patch could stabilize somewhat so that committers can review it
properly and eventually merge it.

Concerning your benchmark:
I don't know exactly what you're measuring, but when performing I/O-related
benchmarks, it's always a good idea to run each test several times in a row, or
flush the page/buffer cache before each run: the reason is that the the second
run benefits from the page/buffer cache, which often speeds things up
dramatically.
Example:

# time find /lib -type f -exec cat {} \; > /dev/null 
real    0m20.455s
user    0m8.145s
sys     0m5.256s

# time find /lib -type f -exec cat {} \; > /dev/null 
real    0m6.827s
user    0m8.477s
sys     0m4.804s

# echo 3 > /proc/sys/vm/drop_caches 

# time find /lib -type f -exec cat {} \; > /dev/null 
real    0m19.954s
user    0m8.069s
sys     0m5.364s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sun May 15 22:21:25 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 15 May 2011 20:21:25 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305490885.47.0.754994715442.issue12081@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

On windows work with patched version of library . Unpatched does not work but I cannot remember python issue number.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12081>
_______________________________________

From report at bugs.python.org  Sun May 15 22:24:09 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 May 2011 20:24:09 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305491049.54.0.156907178634.issue12081@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Has the patch been sent to libffi upstream? What was the response from libffi upstream?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12081>
_______________________________________

From report at bugs.python.org  Sun May 15 23:18:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2011 21:18:54 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1305494334.82.0.810330809239.issue12080@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/issue12080>
_______________________________________

From report at bugs.python.org  Mon May 16 00:24:33 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 15 May 2011 22:24:33 +0000
Subject: [issue1615158] POSIX capabilities support
In-Reply-To: <1305436389.19.0.867066186348.issue1615158@psf.upfronthosting.co.za>
Message-ID: <4DD0529E.7010502@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The development headers for these are not installed by default on
> some distributions.

This is not an issue at all - that's what autoconf is for.

> Adding this to the posix module would enforce linking with lcap and
> lattr always.

That's a more serious problem, IMO; I think some people won't like the
additional dependency.

> I think it would be better if they are added to a separate module

Can you propose a name for the module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Mon May 16 00:44:35 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 15 May 2011 22:44:35 +0000
Subject: [issue9667] NetBSD curses KEY_* constants
In-Reply-To: <1282644914.67.0.328045909398.issue9667@psf.upfronthosting.co.za>
Message-ID: <1305499475.23.0.705214627448.issue9667@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

unassigning, i don't have time to tackle netbsd issues right now.

----------
assignee: gregory.p.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9667>
_______________________________________

From report at bugs.python.org  Mon May 16 00:54:47 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 15 May 2011 22:54:47 +0000
Subject: [issue7656] test_hashlib fails on some installations (specifically
	Neal's regression test runner)
In-Reply-To: <1262914113.09.0.614913015599.issue7656@psf.upfronthosting.co.za>
Message-ID: <1305500087.41.0.440014880551.issue7656@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Misc/build.sh seems obsolete... its full of references to svn and we have had buildbots for many years now.

The buildbots do not seem to be hitting this issue.  Is there a real failure you can point at somewhere?  if so please reopen this with a pointer to that or with full details of how to reproduce it.  platform, os, configure flags, etc.

----------
assignee: gregory.p.smith -> 
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7656>
_______________________________________

From report at bugs.python.org  Mon May 16 00:57:27 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 15 May 2011 22:57:27 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1305500247.63.0.84124310145.issue11197@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

unassigning, i don't have time for this one right now.  doubtful anyone is going to jump in for 3.2.1 given rc1 is being prepared right now. :)

General recommendation: don't use SimpleHTTPServer in production.

----------
assignee: gregory.p.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Mon May 16 01:45:19 2011
From: report at bugs.python.org (Josh Triplett)
Date: Sun, 15 May 2011 23:45:19 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>


New submission from Josh Triplett <josh at joshtriplett.org>:

Even if pyconfig.h defines DONT_HAVE_STAT and DONT_HAVE_FSTAT (which prevents the definitions of HAVE_STAT and HAVE_FSTAT), Python still references fstat in Python/import.c, along with struct stat and constants like S_IXUSR.  I ran into this when attempting to compile Python for an embedded platform, which has some basic file operations but does not have stat.  (I will likely end up faking fstat for now, but I'd rather not have to do so.)

----------
components: Build
messages: 136055
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Mon May 16 01:49:41 2011
From: report at bugs.python.org (Josh Triplett)
Date: Sun, 15 May 2011 23:49:41 +0000
Subject: [issue12083] Compile-time option to avoid writing files,
	including generated bytecode
In-Reply-To: <1305503381.77.0.166373977.issue12083@psf.upfronthosting.co.za>
Message-ID: <1305503381.77.0.166373977.issue12083@psf.upfronthosting.co.za>


New submission from Josh Triplett <josh at joshtriplett.org>:

PEP 304 provides a runtime option to avoid saving generating bytecode files.  However, for embedded usage, it would help to have a compile-time option to remove all the file-writing code entirely, hardcoding PYTHONBYTECODEBASE="".  I ran into this when porting Python to an embedded platform, which will never support any form of filesystem write operations; currently, I have to provide dummy functions for writing files, which error out when attempting to write to anything other than stdout or stderr.

----------
components: Build
messages: 136056
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: Compile-time option to avoid writing files, including generated bytecode
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12083>
_______________________________________

From report at bugs.python.org  Mon May 16 02:09:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 16 May 2011 00:09:18 +0000
Subject: [issue12083] Compile-time option to avoid writing files,
	including generated bytecode
In-Reply-To: <1305503381.77.0.166373977.issue12083@psf.upfronthosting.co.za>
Message-ID: <1305504558.63.0.311617881701.issue12083@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This request is out of scope for 2.7. It is a new feature, and no new features can be added to 2.7.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12083>
_______________________________________

From report at bugs.python.org  Mon May 16 03:40:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2011 01:40:08 +0000
Subject: [issue7656] test_hashlib fails on some installations (specifically
	Neal's regression test runner)
In-Reply-To: <1262914113.09.0.614913015599.issue7656@psf.upfronthosting.co.za>
Message-ID: <1305510008.0.0.767976103946.issue7656@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

AFAIK build.sh is only as out of date as the svn/hg switchover.  I believe this particular issue was dealt with, but I haven't checked.

It runs the refcount tests for 2.7 (Antoine has a separate script that runs them for 3.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7656>
_______________________________________

From report at bugs.python.org  Mon May 16 03:48:06 2011
From: report at bugs.python.org (Dan Stromberg)
Date: Mon, 16 May 2011 01:48:06 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1305510486.03.0.561493175363.issue6715@psf.upfronthosting.co.za>


Dan Stromberg <strombrg at gmail.com> added the comment:

Interesting thing to consider: maybe it'd be better to add support for libarchive, which includes xz support among other things.

http://code.google.com/p/libarchive/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon May 16 03:51:57 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 May 2011 01:51:57 +0000
Subject: [issue11898] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1305484200.4.0.764261304288.issue11898@psf.upfronthosting.co.za>
Message-ID: <20110516015149.GA2808@kevin>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The bug was about sending Binary "data" via httplib. In the example you
wrote, you are sending a unicode "url" and experiencing a failure for
certain examples.

In the 2.7, the urls should be str type, we don't have function to
deal with unicode url separately and sending of unicode url is an
error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11898>
_______________________________________

From report at bugs.python.org  Mon May 16 04:38:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 May 2011 02:38:18 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1305513498.43.0.287176966653.issue7969@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I also found the doc confusing. Does "This exception collects exceptions that raised during a multi-file operation." that Error is used for .rmtree or .move? If so, what format. If not, revise. And I also wondered how to access and use an Error.

----------
nosy: +terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Mon May 16 04:53:22 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 16 May 2011 02:53:22 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. I noticed os.stat() on windows may traverse wrong path on relative symbolic when current working directory != the directory where symbolic link is in. This is because the relative path DeviceIoControl() returns is just passed to win32_xstat without converting to absolute path.

I'm sorry because I implemented this function, and it's hard for me to debug this because I don't have Vista/7. This patch uses GetFinalPathNameByHandle like original code does, plus should handle symlink to system locked file.

Can anyone test and commit this patch?

----------
components: Windows
files: patches_v2.tar.gz
keywords: 3.2regression
messages: 136062
nosy: georg.brandl, ocean-city
priority: release blocker
severity: normal
stage: patch review
status: open
title: os.stat() on windows doesn't consider relative symlink
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22006/patches_v2.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 16 04:58:51 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 16 May 2011 02:58:51 +0000
Subject: [issue9927] Leak around GetFinalPathNameByHandle (Windows)
In-Reply-To: <1285256348.46.0.508900650323.issue9927@psf.upfronthosting.co.za>
Message-ID: <1305514731.62.0.671299075752.issue9927@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'll close this entry because #12084 contains this fix.

----------
status: open -> closed
superseder:  -> os.stat() on windows doesn't consider relative symlink

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9927>
_______________________________________

From report at bugs.python.org  Mon May 16 05:08:55 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Mon, 16 May 2011 03:08:55 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>


New submission from Oleg Oshmyan <chortos at inbox.lv>:

If subprocess.Popen is called with a keyword argument whose name is undefined or simply too many arguments, an instance of the Popen class is created but its __init__ method call fails due to the invalid argument list. (Immediately) afterwards, the new instance is destroyed and its __del__ method is called, which checks the _child_created field that is defined by __init__; but __init__ never got the chance to execute, so the field is not defined, and __del__ raises an AttributeError, which is written out to stderr.

>>> subprocess.Popen(fdsa=1)
Exception AttributeError: "'Popen' object has no attribute '_child_created'" in <bound method Popen.__del__ of <subprocess.Popen object at 0x1006ee790>> ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got an unexpected keyword argument 'fdsa'
>>> subprocess.Popen((), 0, None, None, None, None, None, True, False, None, None, False, None, 0, True, False, (), None)
Exception AttributeError: "'Popen' object has no attribute '_child_created'" in <bound method Popen.__del__ of <subprocess.Popen object at 0x1006ee790>> ignored
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() takes at most 18 positional arguments (19 given)

I encountered this while trying to write a piece of code compatible with Python 3.2 and earlier versions simultaneously. The subprocess module in Python 3.2 adds a new argument to the constructor of Popen, pass_fds, while changing the default value of another, close_fds, from False to True. In order to utilize pass_fds, I tried code that looked like this:

    try:
        process = Popen(*args, pass_fds=myfds, **kwargs)
    except TypeError:
        process = Popen(*args, **kwargs)

It worked but printed a message about the exception in __del__, which interfered with my own output. Without delving too much into the details of my code, I ended up just passing close_fds=False.

The attached patch avoids the exception by converting the reference to _child_created in __del__ into a three-argument getattr call.

----------
components: Library (Lib)
files: _child_created.diff
keywords: patch
messages: 136064
nosy: chortos
priority: normal
severity: normal
status: open
title: subprocess.Popen.__del__ raises AttributeError if __init__ was called with an invalid argument list
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22007/_child_created.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Mon May 16 05:26:58 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 16 May 2011 03:26:58 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305516418.36.0.327822351657.issue12084@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/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 16 05:28:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 03:28:00 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1305516480.77.0.791517162476.issue12082@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, so it's possible to not have the fstat() syscall. I asked me the question when I modified import.c (and other files related to importing a module).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Mon May 16 06:32:50 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 16 May 2011 04:32:50 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1305520370.24.0.993631944009.issue1615158@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> > I think it would be better if they are added to a separate module

> Can you propose a name for the module?

I would say either posixcap or capabitilies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Mon May 16 06:34:28 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 16 May 2011 04:34:28 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1305520468.05.0.196737956722.issue1615158@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> I would say either posixcap or capabitilies.

The problem with capabilities is that it's easy to misspell, as I did :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Mon May 16 07:42:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 May 2011 05:42:13 +0000
Subject: [issue12079] decimal.py: TypeError precedence in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <1305524533.8.0.5061362292.issue12079@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12079>
_______________________________________

From report at bugs.python.org  Mon May 16 07:54:24 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 16 May 2011 05:54:24 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305525264.45.0.143981875117.issue1746656@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

All the buildbots are back to normal. It looks like FreeBSD was having
the same problem as OS X.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Mon May 16 08:02:37 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 16 May 2011 06:02:37 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305525757.07.0.0674813408274.issue12084@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It's quite a large patch... :)

I now own a new laptop that had Windows 7 preinstalled, so I'll try to get set up VC++ Express, and then test the patch. Still I'm nosying Martin as well.

For the future, it's much easier to just attach both files individually, this saves the need to download and unpack the archive.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 16 08:39:56 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 16 May 2011 06:39:56 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305527996.23.0.0609207700473.issue12084@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 16 09:13:27 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 16 May 2011 07:13:27 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1305510486.03.0.561493175363.issue6715@psf.upfronthosting.co.za>
Message-ID: <4DD0CE96.7040201@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> maybe it'd be better to add support for libarchive

That wouldn't be better. We want the C dependency as small
and low-level as possible, so that the dependency is small
and the functionality flexible to implement stuff in Python
on top of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon May 16 09:52:35 2011
From: report at bugs.python.org (dario frascatani)
Date: Mon, 16 May 2011 07:52:35 +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: <1305532355.03.0.821043453645.issue12013@psf.upfronthosting.co.za>


dario frascatani <dgfrascatani at gmail.com> added the comment:

I have some problem to compile python source code to my server, I can't install make.
My problem is only when import the smtplib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Mon May 16 10:35:44 2011
From: report at bugs.python.org (Radomir Dopieralski)
Date: Mon, 16 May 2011 08:35:44 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>


New submission from Radomir Dopieralski <python-bugs at sheep.art.pl>:

In the tutorial, at http://docs.python.org/tutorial/classes.html#private-variables you can read:

----
9.6. Private Variables
?Private? instance variables that cannot be accessed except from inside an object don?t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API (whether it is a function, a method or a data member). It should be considered an implementation detail and subject to change without notice.

Since there is a valid use-case for class-private members (namely to avoid name clashes of names with names defined by subclasses), there is limited support for such a mechanism, called name mangling. Any identifier of the form __spam (at least two leading underscores, at most one trailing underscore) is textually replaced with _classname__spam, where classname is the current class name with leading underscore(s) stripped. This mangling is done without regard to the syntactic position of the identifier, as long as it occurs within the definition of a class.

Note that the mangling rules are designed mostly to avoid accidents; it still is possible to access or modify a variable that is considered private. This can even be useful in special circumstances, such as in the debugger.

[...]
----

I think that this section doesn't stress enough how special the "__foo" syntax is and how rarely it should be used. If I was a programmer coming from Java to Python, I would start using "__foo" everywhere after reading this. I actually receive code written like that from programmers new to Python, and they point to that section of documentation when I ask why they did it.

At minimum, I'd add a paragraph that warns about how name mangling makes the code hard to reuse, difficult to test and unpleasant to debug.

----------
assignee: docs at python
components: Documentation
messages: 136072
nosy: docs at python, sheep
priority: normal
severity: normal
status: open
title: Tutorial doesn't discourage name mangling
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 16 10:37:38 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 16 May 2011 08:37:38 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305535058.5.0.316089960735.issue12086@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee: docs at python -> lukasz.langa
nosy: +lukasz.langa
stage:  -> needs patch
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 16 10:42:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 16 May 2011 08:42:27 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305535347.4.0.489008796507.issue12086@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No warnings, please.  See http://docs.python.org/documenting/style.html#affirmative-tone and related sections.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 16 10:52:19 2011
From: report at bugs.python.org (Tim Golden)
Date: Mon, 16 May 2011 08:52:19 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305535939.44.0.271839785599.issue12086@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

But at the least, the start of the para might be slightly reworded to something like: "If you specifically need to avoid name clashes with subclasses, there is limited support..." which avoids the phrase "Since there is a valid use-case for class-private members".

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 16 10:54:41 2011
From: report at bugs.python.org (Radomir Dopieralski)
Date: Mon, 16 May 2011 08:54:41 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305536081.84.0.730354011027.issue12086@psf.upfronthosting.co.za>


Radomir Dopieralski <python-bugs at sheep.art.pl> added the comment:

"In the unlikely case that you specifically need to avoid name clashes with subclasses, there is limited support..." ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 16 11:34:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 16 May 2011 09:34:19 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305538459.87.0.21843464717.issue12086@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think the main problem here is that they are called "private" and people coming from other languages assume that the double underscore is the Python way to mark variables as private, whereas the appearance of being private is just a side effect of the name mangling.

This part should IMHO focus on the name mangling, explaining what it is and what it's useful for, and mention clearly that this doesn't really make the variable "private", because it can still be accessed through the mangled name.

The section could also mention that the word "private" here doesn't mean the same thing as in other language.

I don't know if the "trust the programmer" philosophy found in Python is explained somewhere in the doc, but if not it could be added to the tutorial or the FAQ.

----------
nosy: +ezio.melotti, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 16 12:17:57 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 16 May 2011 10:17:57 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305541077.16.0.720223678781.issue12086@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I'd like to see that section gone altogether. The tutorial is designed to be the first point of contact with the language. In that context name mangling is an obscure detail with an unlikely use case.

If anything, the tutorial should simply state that private variables are by convention prepended with a single underscore. Maybe there's place for a separate short article which would nicely explain the philosophy behind the lack of an enforcing `private` modifier. The "we're all consenting adults here" stuff.

Agreed with Ezio that "private" is in itself a poor name for what underscore (regardless whether a single one or two) really means.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 16 13:25:56 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 16 May 2011 11:25:56 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1305545156.44.0.886357856543.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Also, if I'm reading the documentation correctly, there isn't any
support for incremental in-memory coding, so it wouldn't be possible
to implement classes analogous to BZ2Compressor/BZ2Decompressor.

----------
assignee:  -> nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon May 16 13:45:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 16 May 2011 11:45:58 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1305546358.51.0.365633367049.issue12077@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Mon May 16 13:51:53 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 May 2011 11:51:53 +0000
Subject: [issue1748064] inspect.getargspec fails on built-in or slot wrapper
	methods
Message-ID: <1305546713.41.0.140246648214.issue1748064@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/issue1748064>
_______________________________________

From report at bugs.python.org  Mon May 16 13:52:38 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 May 2011 11:52:38 +0000
Subject: [issue12038] assertEqual doesn't display newline differences quite
	well
In-Reply-To: <1304959012.21.0.957539258305.issue12038@psf.upfronthosting.co.za>
Message-ID: <1305546758.53.0.221677776323.issue12038@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Yep, ensuring the truncated repr includes at least the *first* difference sounds like the right approach.

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12038>
_______________________________________

From report at bugs.python.org  Mon May 16 13:54:32 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 May 2011 11:54:32 +0000
Subject: [issue1748064] inspect.getargspec fails on built-in or slot wrapper
	methods
Message-ID: <1305546872.37.0.435564118014.issue1748064@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

If PEP 362 is implemented it would either fix or obsolete this issue:

http://www.python.org/dev/peps/pep-0362/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1748064>
_______________________________________

From report at bugs.python.org  Mon May 16 13:56:20 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 May 2011 11:56:20 +0000
Subject: [issue1748064] inspect.getargspec fails on built-in or slot wrapper
	methods
Message-ID: <1305546980.97.0.00415364539654.issue1748064@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sorry, *could* fix / obsolete this issue. i.e. builtin functions / methods could support pep 362 - the reference implementation is in pure python and doesn't work for C functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1748064>
_______________________________________

From report at bugs.python.org  Mon May 16 14:00:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 16 May 2011 12:00:22 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1305547222.01.0.465758631111.issue9938@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW unittest had a similar issue and it's been solved adding an 'exit' argument to unittest.main() [0].

I think using an attribute here might be fine.
The patch contains some trailing whitespace that should be removed, also it might be enough to name the attribute "exit_on_error".
It should also include tests to check that the attribute is set with the correct default value and that it doesn't raise SystemExit when the attribute is False.

[0]: http://docs.python.org/library/unittest.html#unittest.main

----------
nosy: +ezio.melotti
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Mon May 16 14:05:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 May 2011 12:05:41 +0000
Subject: [issue1748064] inspect.getargspec fails on built-in or slot wrapper
	methods
Message-ID: <1305547541.6.0.481660670425.issue1748064@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The challenge with C functions is that this becomes *additional* metadata that somehow needs to be provided to the method and function creation process. None of our APIs are set up to accept that information (and obviously no code is set up to provide it, either).

What might be nice is a way to graft the signature information from a Python implementation onto a C implementation (which would be quite straightforward given PEP 362 and a writable __signature__ slot in the C objects).

The other virtue of this approach is that the Python metadata will be testable, so it doesn't run the same risk of getting out of date that manually maintained metadata at the C level does. It would work naturally for C acceleration modules, and wouldn't be any more effort to add for pure C code than direct annotations at the C level would be.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1748064>
_______________________________________

From report at bugs.python.org  Mon May 16 14:21:36 2011
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 16 May 2011 12:21:36 +0000
Subject: [issue12087] install_egg_info fails with UnicodeEncodeError depending
	on locale
In-Reply-To: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>
Message-ID: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hagen at zhuliguan.net>:

With issue 10419 fixed, I've run into the next distutils unicode bug: The command "install_egg_info" doesn't specify an encoding when opening the ".egg-info" file for writing. Depending on the locale, this may result in something like the following:

$ python setup.py install
[...]
Traceback (most recent call last):
  File "setup.py", line 67, in <module>
    main()
  File "setup.py", line 62, in main
    cmdclass={"test":TestCommand},
  File "/home/hagen/src/python/Lib/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/home/hagen/src/python/Lib/distutils/command/install.py", line 583, in run
    self.run_command(cmd_name)
  File "/home/hagen/src/python/Lib/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/home/hagen/src/python/Lib/distutils/command/install_egg_info.py", line 44, in run
    self.distribution.metadata.write_pkg_file(f)
  File "/home/hagen/src/python/Lib/distutils/dist.py", line 1033, in write_pkg_file
    file.write('Author: %s\n' % self.get_contact() )
UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 15: ordinal not in range(128)


I guess some encoding (UTF-8?) should be specified in the "run" method of "install_egg_info".

----------
assignee: tarek
components: Distutils
messages: 136084
nosy: eric.araujo, hagen, tarek
priority: normal
severity: normal
status: open
title: install_egg_info fails with UnicodeEncodeError depending on locale
type: crash
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12087>
_______________________________________

From report at bugs.python.org  Mon May 16 14:26:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 12:26:31 +0000
Subject: [issue12087] install_egg_info fails with UnicodeEncodeError depending
	on locale
In-Reply-To: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>
Message-ID: <1305548791.99.0.869678250346.issue12087@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

install_egg_info.run() uses f = open(target, 'w') to create the .egg-info file and so the file uses the locale encoding. I don't know which module/program reads the file, so I don't know if the "locale encoding" is a good choice.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12087>
_______________________________________

From report at bugs.python.org  Mon May 16 14:54:36 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 16 May 2011 12:54:36 +0000
Subject: [issue12075] python3.2 memory leak when setting integer key in
	dictionary
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1305550476.24.0.31261575864.issue12075@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/issue12075>
_______________________________________

From report at bugs.python.org  Mon May 16 15:19:36 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 16 May 2011 13:19:36 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1305551976.4.0.0698628799125.issue12081@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/issue12081>
_______________________________________

From report at bugs.python.org  Mon May 16 15:50:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 13:50:14 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1305553814.33.0.339798433186.issue12028@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@pitrou: What do you think Antoine?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 16 15:51:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 May 2011 13:51:59 +0000
Subject: [issue12040] Expose a Process.sentinel property (and fix polling loop
	in Process.join())
In-Reply-To: <1305306598.13.0.230696925853.issue12040@psf.upfronthosting.co.za>
Message-ID: <1305553915.3623.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Just a detail, but with the last version, select is retried with the
> full timeout (note that the signal you're the most likely to receive
> is SIGCHLD and since it's ignored by default it won't cause EINTR, so
> this shouldn't happen too often).

Indeed, it is. In practice we don't see anyone complaining about EINTR
issues, so I guess it's quite rare anyway.

> By the way, it's not the first time EINTR-issues pop up: would it be
> possible/worth it/interesting to expose this kind of wrapper somewhere
> (even as a private API), or a context manager ?

Yes, but where?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12040>
_______________________________________

From report at bugs.python.org  Mon May 16 15:56:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 13:56:24 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1305554184.8.0.622730726334.issue12028@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The threading API changed in Python 3 with the PEP 3108, especially and issue #2875. Extract of the PEP:

"thread [done]

 * People should use 'threading' instead.
   * Rename 'thread' to _thread.
   * Deprecate dummy_thread and rename _dummy_thread.
   * Move thread.get_ident over to threading.
 * Guido has previously supported the deprecation [13]."

The issue was closed by the commit [7fe3a8648ce2], "Issue #2875: Rename thread to _thread and dummy_thread to _dummy_thread."

----------
nosy: +brett.cannon, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 16 15:59:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 May 2011 13:59:01 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1305554341.9.0.0247768970734.issue12028@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think that threading._get_ident() is more reliable than
> threading.current_thread().ident because Thread.ident can be None in
> some cases.

In which case can it be None?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 16 16:00:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 May 2011 14:00:08 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <BANLkTi=sw1pdk_r5haUYbtiGZGfto68SMw@mail.gmail.com>
Message-ID: <1305554405.3623.21.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thus,
> Connection.recv_bytes() will be called:
> 
>     def _recv_bytes(self, maxsize=None):
>         buf = self._recv(4)
>         size, = struct.unpack("=i", buf.getvalue())
>         if maxsize is not None and size > maxsize:
>             return None
>         return self._recv(size)
> 
> The first _recv() will succeed, since the length is in the Pipe.
> The second one, however, will remain stuck on the read from the
> pipe/unix socket, because there's no more data.
> This can be reproduced easily by adding a short sleep right after the
> sending of the length of the buffer inside send_bytes(), and then
> sending a SIGKILL to a worker process.

That's true. We would need to insert a select() before each raw read().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Mon May 16 16:01:05 2011
From: report at bugs.python.org (Scott Leerssen)
Date: Mon, 16 May 2011 14:01:05 +0000
Subject: [issue12088] tarfile.extractall fails to overwrite unresolved
	symlinks and hard links
In-Reply-To: <1305554464.99.0.852518621485.issue12088@psf.upfronthosting.co.za>
Message-ID: <1305554464.99.0.852518621485.issue12088@psf.upfronthosting.co.za>


New submission from Scott Leerssen <sleerssen at gmail.com>:

I'm opening this as a continuation of issue10761 since it was closed as fixed, and there's a bit more work to do there.

The fix for issue10761 was incomplete.  It did not handle the case where the symlink being overwritten did not resolve to another file (i.e. a "broken" link).  It also did not address the same issues with hard links.

The comments starting at http://bugs.python.org/issue10761#msg135924 detail the updates needed to complete this fix.

----------
components: Library (Lib)
messages: 136091
nosy: Scott.Leerssen
priority: normal
severity: normal
status: open
title: tarfile.extractall fails to overwrite unresolved symlinks and hard links
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12088>
_______________________________________

From report at bugs.python.org  Mon May 16 16:12:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 14:12:19 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1305555139.51.0.921637009637.issue12028@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> In which case can it be None?

Oh, I misunderstood threading.py. current_thread().ident cannot be None.

During the bootstrap of a thread, Thread._ident is None, but current_thread().ident is not None because current_thread() creates a dummy thread object having the right identifer. This dummy object is destroyed at soon as the Thread object is started (see Thread._bootstrap_inner).

current_thread().ident is a little bit "suboptimal" because it gets the identifier of the thread, it reads the corresponding thread object, and then it gets the identifier of the thread object.

def current_thread():
    ...
    return _active[_get_ident()]
    ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 16 16:22:45 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 May 2011 14:22:45 +0000
Subject: [issue12088] tarfile.extractall fails to overwrite unresolved
	symlinks and hard links
In-Reply-To: <1305554464.99.0.852518621485.issue12088@psf.upfronthosting.co.za>
Message-ID: <1305555765.34.0.484427153494.issue12088@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I looked at your message and the patch, seems okay for the case of testing if the symlink is broken and performing the next steps. I shall commit it soon.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12088>
_______________________________________

From report at bugs.python.org  Mon May 16 16:31:16 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 May 2011 14:31:16 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1305556276.03.0.458464363747.issue1615158@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Another possibility is to make it a private module _posixcapabilities, which would be used in os module:

try:
    from _posixcapabilities import *
except ImportError:
    pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Mon May 16 16:35:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2011 14:35:46 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <E1QLytd-0007Ey-Bw@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 44fd95cead7b by Victor Stinner in branch '3.1':
Issue #11614: import __hello__ prints "Hello World!". Patch written by Andreas
http://hg.python.org/cpython/rev/44fd95cead7b

New changeset 2c5736e8a221 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #11614: import __hello__ prints "Hello World!". Patch written
http://hg.python.org/cpython/rev/2c5736e8a221

New changeset 79c49d2fc768 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11614: import __hello__ prints "Hello World!". Patch written
http://hg.python.org/cpython/rev/79c49d2fc768

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Mon May 16 16:37:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 14:37:03 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305556623.19.0.912402461902.issue11614@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks Andreas for your fix! Python 3 is now better than Python 2: it prints "Hello World!" instead of "Hello World...".

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Mon May 16 16:38:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 May 2011 14:38:46 +0000
Subject: [issue1615158] POSIX capabilities support
Message-ID: <1305556726.81.0.907941336796.issue1615158@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

"posixcap" sounds ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Mon May 16 16:44:13 2011
From: report at bugs.python.org (Alex Lai)
Date: Mon, 16 May 2011 14:44:13 +0000
Subject: [issue12013] file
	/usr/local/lib/python3.1/lib-dynload/_socket.so:	symbol
	inet_aton: referenced symbol not found
In-Reply-To: <1305532355.03.0.821043453645.issue12013@psf.upfronthosting.co.za>
Message-ID: <BDAB2503F626C149AD67860EA418BFB00F1416B665@SCTORMAIL6.scglobal.ad.scotiacapital.com>


Alex Lai <alex_lai at scotiacapital.com> added the comment:

I install the Python package compiled by sunfreeware.

Alex Lai

Senior System Support Specialist
TAG-IPM Application Support, Scotia Capital,
720 King St. West, 6th Floor,
Toronto, Ontario M5V 2T3
Tel: (416) 607-4789
-----Original Message-----
From: dario frascatani [mailto:report at bugs.python.org] 
Sent: May 16, 2011 3:53 AM
To: Alex Lai (Scotia Capital)
Subject: [issue12013] file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found

dario frascatani <dgfrascatani at gmail.com> added the comment:

I have some problem to compile python source code to my server, I can't install make.
My problem is only when import the smtplib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

---
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distributing or disclosing same. No member of the Scotiabank Group is liable for any errors or omissions in the content or transmission of this email or accepts any responsibility or liability for loss or damage arising from the receipt or use of this transmission. Scotiabank Group may monitor, retain and/or review email. Trading instructions received by e-mail or voicemail will not be accepted or acted upon. Unless indicated in writing, opinions contained in this email are those of the author and are not endorsed by any member of the Scotiabank Group. 

For information on some members of the Scotiabank Group: http://www.scotiacapital.com/EmailDisclaimer/English_entities.htm
For authorized users of the Scotia Capital trademark: http://www.scotiacapital.com/EmailDisclaimer/English_trademark.htm

Pour obtenir la traduction en fran?ais: http://www.scotiacapital.com/EmailDisclaimer/French.htm
Traducci?n en espa?ol: http://www.scotiacapital.com/EmailDisclaimer/Spanish.htm

----------
title: file /usr/local/lib/python3.1/lib-dynload/_socket.so: symbol inet_aton: referenced symbol not found -> file /usr/local/lib/python3.1/lib-dynload/_socket.so:	symbol inet_aton: referenced symbol not found

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12013>
_______________________________________

From report at bugs.python.org  Mon May 16 16:50:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2011 14:50:37 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QLz7z-0000e3-Qe@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 16503022c4b8 by Victor Stinner in branch '3.1':
Issue #12057: Convert CJK encoding testcase BLOB into multiple text files
http://hg.python.org/cpython/rev/16503022c4b8

New changeset 370db8da308f by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12057: Convert CJK encoding testcase BLOB into multiple text
http://hg.python.org/cpython/rev/370db8da308f

New changeset e7daf2acc3a7 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12057: Convert CJK encoding testcase BLOB into multiple text
http://hg.python.org/cpython/rev/e7daf2acc3a7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Mon May 16 16:58:40 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 16 May 2011 14:58:40 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305557920.46.0.513509202468.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've made some progress on this issue. Thanks to Waldemar's findings, I'm able to selectively reproduce the issue by installing/uninstalling the Visual C++ redistributable that includes KB2467174 on a Windows 7 RTM installation.

So I added a patch to cpython to help troubleshoot:

    PS C:\Users\jaraco\projects\public\cpython\pcbuild> hg id
    434dfe42fde1+
    PS C:\Users\jaraco\projects\public\cpython\pcbuild> hg diff
    diff -r 434dfe42fde1 Python/import.c
    --- a/Python/import.c   Sun May 15 13:16:22 2011 +0200
    +++ b/Python/import.c   Mon May 16 10:52:45 2011 -0400
    @@ -1807,6 +1807,15 @@
         /* Check for package import (buf holds a directory name,
            and there's an __init__ module in that directory */
     #ifdef HAVE_STAT
    +    if (Py_VerboseFlag > 1 && _Py_stat(filename, &statbuf) == 0) {
    +        PySys_FormatStderr("stat_mode %U: %d\n",
    +                           filename, statbuf.st_mode);
    +    }
    +    else if(Py_VerboseFlag > 1)
    +    {
    +        PySys_FormatStderr("_Py_stat(%U) returned %d\n",
    +            filename, _Py_stat(filename, &statbuf));
    +    }
         if (_Py_stat(filename, &statbuf) == 0 &&         /* it exists */
             S_ISDIR(statbuf.st_mode))           /* it's a directory */
         {


I then ran the test script without vcredist:

    C:\Users\Jason R. Coombs\Desktop>u:\users\jaraco\projects\public\cpython\pcbuild\amd64\python -vv .\test_import_symlink_package.py   2>&1  | findstr sample
    stat_mode .\sample: 16895
    import sample # directory '.\\sample'
    _Py_stat(.\sample\__init__) returned -1
    # trying '.\\sample\\__init__.pyd'
    # trying '.\\sample\\__init__.py'
    import sample # from '.\\sample\\__init__.py'
    # wrote '.\\sample\\__pycache__\\__init__.cpython-32.pyc'
    # cleanup[1] sample

And again with the vcredist installed:

    C:\Users\Jason R. Coombs\Desktop>u:\users\jaraco\projects\public\cpython\pcbuild\amd64\python -vv .\test_import_symlink_package.py   2>&1  | findstr sample
    _Py_stat(.\sample) returned -1
    # trying '.\\sample.pyd'
    # trying '.\\sample.py'
    # trying '.\\sample.pyw'
    # trying '.\\sample.pyc'
    No module named 'sample'

Basically, it appears that with the later vcredist installed, _Py_stat is returning -1 for symlink directories.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Mon May 16 17:01:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2011 15:01:29 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <E1QLzIW-000265-2X@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9e1d7cd15d2e by Victor Stinner in branch '3.1':
Issue #11614: Fix importlib tests for the new __hello__ module
http://hg.python.org/cpython/rev/9e1d7cd15d2e

New changeset 6119f6cc9b2d by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #11614: Fix importlib tests for the new __hello__ module
http://hg.python.org/cpython/rev/6119f6cc9b2d

New changeset b61a1cd4943b by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11614: Fix importlib tests for the new __hello__ module
http://hg.python.org/cpython/rev/b61a1cd4943b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Mon May 16 17:12:20 2011
From: report at bugs.python.org (=?utf-8?q?Ana_Sofia_Paix=C3=A3o?=)
Date: Mon, 16 May 2011 15:12:20 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1305558740.36.0.111092862924.issue4966@psf.upfronthosting.co.za>


Ana Sofia Paix?o <anasofiapaixao at gmail.com> added the comment:

I was taking a look into the possibility of splitting this page into several pages, and wondered: could the contents of the Comparisons and the Boolean operations sections just be merged into Python Reference / Expressions, and then deleted from this page altogether? They are not even data types but operators, after all.

----------
nosy: +anasofiapaixao

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4966>
_______________________________________

From report at bugs.python.org  Mon May 16 17:14:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 15:14:04 +0000
Subject: [issue12089] regrtest.py doesn't check for unexpected output anymore?
In-Reply-To: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>
Message-ID: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In Python 3.1, a test fails if it writes to stdout/stderr. It is no more the case in Python 3.2 and 3.3. Why? If we decided to not check for unexpected output in Python 3.2+, the following code should be removed:

    if verbose:
        capture_stdout = None
    else:
        capture_stdout = io.StringIO()

----------
components: Tests
messages: 136103
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest.py doesn't check for unexpected output anymore?
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12089>
_______________________________________

From report at bugs.python.org  Mon May 16 17:16:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2011 15:16:30 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QLzX2-0003rD-On@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1bd697cdd210 by Victor Stinner in branch '2.7':
Issue #12057: Convert CJK encoding testcase BLOB into multiple text files
http://hg.python.org/cpython/rev/1bd697cdd210

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Mon May 16 17:20:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2011 15:20:55 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <E1QLzbJ-0004Si-RB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9a4d4506680a by Victor Stinner in branch '3.1':
Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't exist anymore
http://hg.python.org/cpython/rev/9a4d4506680a

New changeset 43cbfacae463 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't
http://hg.python.org/cpython/rev/43cbfacae463

New changeset 06473da99270 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't
http://hg.python.org/cpython/rev/06473da99270

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Mon May 16 17:23:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 15:23:08 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305559388.62.0.500559268834.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I specified the wrong issue number of my last 3 commits: test_linecache failure is related to this issue.

New changeset 9a4d4506680a by Victor Stinner in branch '3.1':
Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't exist anymore
http://hg.python.org/cpython/rev/9a4d4506680a

New changeset 43cbfacae463 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't
http://hg.python.org/cpython/rev/43cbfacae463

New changeset 06473da99270 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't
http://hg.python.org/cpython/rev/06473da99270

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Mon May 16 17:23:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2011 15:23:34 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1305559414.17.0.0985669736067.issue11614@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset 9a4d4506680a by Victor Stinner in branch '3.1':
> Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't exist anymore

Oh, these commits are related to #12057, not this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Mon May 16 17:38:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 16 May 2011 15:38:33 +0000
Subject: [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1305560313.64.0.00447655181396.issue4966@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think it should be OK.  The stdtypes page could then mention type-specific behavior in the types' sections (e.g. <, <=, =>, > for sets) and link to the language reference for the general behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4966>
_______________________________________

From report at bugs.python.org  Mon May 16 17:49:53 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 May 2011 15:49:53 +0000
Subject: [issue12087] install_egg_info fails with UnicodeEncodeError depending
	on locale
In-Reply-To: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>
Message-ID: <1305560993.4.0.971583183826.issue12087@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/issue12087>
_______________________________________

From report at bugs.python.org  Mon May 16 17:51:37 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 May 2011 15:51:37 +0000
Subject: [issue12089] regrtest.py doesn't check for unexpected output anymore?
In-Reply-To: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>
Message-ID: <1305561097.2.0.210197468699.issue12089@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/issue12089>
_______________________________________

From report at bugs.python.org  Mon May 16 18:08:49 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 16 May 2011 16:08:49 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305562129.09.0.852898835092.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Hirokazu contacted me directly with these patches a few days ago but I haven't been able to email him because his host's DNS is apparently down.

The tests in this patch do not end up testing anything, so we'll need to start with a proper test. In the brief look I had the other day, adding an except clause to the outer try/finally block catches something about a file not being available IIRC. I'll take a look this afternoon/evening.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 16 18:10:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 16 May 2011 16:10:24 +0000
Subject: [issue12087] install_egg_info fails with UnicodeEncodeError depending
	on locale
In-Reply-To: <1305548495.94.0.944889224247.issue12087@psf.upfronthosting.co.za>
Message-ID: <1305562224.07.0.216902792994.issue12087@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The pkg_resources module in setuptools or distribute reads those files.

In 3.3, packaging.database reads them too (it?s an implementation of PEP 376 with b/w compat with egg-info).  It may work just fine in 3.x (it uses text I/O), but when we backport packaging to distutils2 for 2.4+, we?ll probably run into the problem again.

----------
components: +Distutils2
nosy: +alexis, pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12087>
_______________________________________

From report at bugs.python.org  Mon May 16 18:35:58 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 16 May 2011 16:35:58 +0000
Subject: [issue1748064] inspect.getargspec fails on built-in or slot wrapper
	methods
Message-ID: <1305563758.53.0.914082580797.issue1748064@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/issue1748064>
_______________________________________

From report at bugs.python.org  Mon May 16 19:26:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 16 May 2011 17:26:39 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1305399033.28.0.945166541094.issue11949@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=f-Y5kVmuxHqwxqbxrfuBV5yMSFA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 14, 2011 at 2:50 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> On the issue itself, I'm -1 on making comparisons with float('nan') raise: I don't see that there's a real problem here that needs solving.
>

I probably should have changed the title of this issue after making an
alternative proposal to make INVALID operations produce a warning:

http://mail.python.org/pipermail/python-ideas/2011-April/010101.html

For the case of nan ordering, this idea seemed to receive support on
the mailing list:

http://mail.python.org/pipermail/python-ideas/2011-April/010102.html
http://mail.python.org/pipermail/python-ideas/2011-April/010103.html
http://mail.python.org/pipermail/python-ideas/2011-April/010104.html

> Note that the current behaviour does *not* violate IEEE 754, since there's nothing anywhere
> in IEEE 754 that says that Python's < operation should raise for comparisons involving NaNs:
> ?all that's said is that a conforming language should provide a number of comparison operations
> (without specifying how those operation should be spelt in the language in question), including
> both a < operation that's quiet (returning a false value for comparison with NaNs) and a <
> operation that signals on comparison with NaN. ?There's nothing to indicate definitively which of
>  these two operations '<' should bind to in a language.
>

Yes, IEEE 754, provides little guidance to language designers, but why
would anyone want to treat
ordering of floats differently from ordering of decimals?

Traceback (most recent call last):
  ..
decimal.InvalidOperation: comparison involving NaN

> It *is* true that C chooses to bind '<' to the signalling version, but that doesn't automatically mean that we should do the same in Python.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11949>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Mon May 16 19:41:43 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 16 May 2011 17:41:43 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305567703.06.0.81333679405.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I decided to investigate further. I created another script to test the call to _wstat to try to recreate the -1 return code, but I was unable to do so. I'm attaching the script, which creates the same 'sample' package, but instead of calling import, calls _wstat directly on the 'sample', but it returns 0, even in the environments where the test script fails.

This leads me to believe the issue isn't with _wstat, but with the way _wstat is called in _Py_stat.

----------
Added file: http://bugs.python.org/file22008/wstat-res.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Mon May 16 19:41:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2011 17:41:52 +0000
Subject: [issue12089] regrtest.py doesn't check for unexpected output anymore?
In-Reply-To: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>
Message-ID: <1305567712.34.0.244764212552.issue12089@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Antoine removed that check as part of the -j support, if I recall correctly.  The check for unexpected output was part of the support for the transition between the old pre-unittest test suite and the unittest based test suite, and does seem like it is obsolete.  Presumably we will visually spot unexpected output during pre-checkin testing.

----------
nosy: +pitrou, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12089>
_______________________________________

From report at bugs.python.org  Mon May 16 19:56:51 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 May 2011 17:56:51 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

The new Fedora buildbot (--without-threads) fails to compile:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.2/builds/1


I didn't check the release branch yet.

----------
components: Build
keywords: buildbot
messages: 136114
nosy: georg.brandl, skrah
priority: normal
severity: normal
status: open
title: 3.2: build --without-threads fails
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Mon May 16 20:20:50 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 16 May 2011 18:20:50 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1305400101.13.0.429344945107.issue11949@psf.upfronthosting.co.za>
Message-ID: <BANLkTimsKt_B+wZ9RsLr3F26VZ6CG_Laqw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 14, 2011 at 3:08 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
>> Note that the current behaviour does *not* violate IEEE 754, ...
>
> I agree with Mark.

Do we really need a popular vote to determine what a published
standard does or does not require?

Section 7.2 of IEEE Std 754-2008 states:

"""
7.2 Invalid operation

The invalid operation exception is signaled if and only if there is no
usefully definable result. In these cases
the operands are invalid for the operation to be performed.
?

For operations producing no result in floating-point format, the
operations that signal the invalid operation exception are:
...
j)	comparison by way of unordered-signaling predicates listed in Table
5.2, when the operands are unordered
"""

Python comparison operators.

We can argue, of course about the proper mapping of IEEE 754 'INVALID'
exception to the available Python construct.  Arguably, a compliant
language can ignore INVALID exceptions, issue a warning while
returning result, or raise an exception and produce no result.  In a
post on Python ideas Mark argued that the ideal disposition of INVALID
is a ValueError:

"""
IMO, the ideal (ignoring backwards compatibility) would be to have
OverflowError / ZeroDivisionError / ValueError produced wherever
IEEE754 says that overflow / divide-by-zero / invalid-operation should
be signaled.
"""
http://mail.python.org/pipermail/python-ideas/2011-April/010106.html

If IEEE 754 compliance is a stated goal in Python design, it would
make very little sense to treat some cases of INVALID differently from
others.  If, however, IEEE 754 compliance is not a goal, we should
consider what is the most useful behavior.   On the mailing list, I
posted a challenge - review your code that will work differently if
nan ordering was disallowed and report whether that code does the
right thing for all kinds of float (including nan, inf and signed 0).
So far, I have not seen any responses to this.

My own experiment with the Python library itself, have revealed a bug
in the test suit.   This matches my prior experience: naive numeric
code usually produces nonsense results when nans are compared and
careful numeric code makes an effort to avoid comparing nans.

> ?Am closing this feature request which is both ill-conceived and likely to cause more harm than good (possibly breaking code that currently does not fail).
>

My primary goal in posting this patch was to support the discussion on
python-ideas.  The patch was not intended to be applied as is.  At the
minimum, I would need to make nan < nan issue a deprecation warning
before turning it into an error.  If this is not an appropriate use of
the tracker - please propose an alternative.  Posting a patch on the
mailing list or outside of python.org seems to be a worse alternative.

>> the discussion about cleaning up test_math
>> (which I agree would be a good thing to do)
>> should probably go into another issue.
>
> I agree.

Why?  The issue in test_math is small enough that it can be fixed
without any discussion on the tracker.  If someone would want to
improve unittest based on this experience, this can indeed be handled
in a separate issue.  As long as the changes are limited to Lib/test,
I don't see what a separate issue will bring other than extra work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Mon May 16 20:27:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 May 2011 18:27:19 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1305570439.27.0.68584204627.issue12090@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

A backport of 79fcd71d0356 fixes the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Mon May 16 20:28:58 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 16 May 2011 18:28:58 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1305570538.25.0.221634131505.issue11949@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

A tracker bug has mangled the following paragraph following the IEEE 754 standard quote in my previous post:

"""
Table 5.2 referenced above lists 10 operations, four of which (>, <,
>=, and <=) are given spellings that are identical to the spellings of
Python comparison operators.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Mon May 16 20:48:56 2011
From: report at bugs.python.org (James Hutchison)
Date: Mon, 16 May 2011 18:48:56 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1305571736.65.0.339393883211.issue11990@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

I would like to add in windows, "input" now adds a \r at the end which wasn't in 3.1. It doesn't do it in idle. This is using just the regular console window that opens up when you double click. I'm guessing this is related to the issue I saw earlier:

code:
from time import sleep

item = input("Input something\n");
print("%s %i" % (item, len(item)));
sleep(15);

in Idle:
Input something
something
something 9

in console window:
Input something
something
 10ething

ouch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11990>
_______________________________________

From report at bugs.python.org  Mon May 16 20:49:29 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 16 May 2011 18:49:29 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1305571769.9.0.68149021269.issue11990@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

That's already fixed, it'll be in 3.2.1

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11990>
_______________________________________

From report at bugs.python.org  Mon May 16 20:57:30 2011
From: report at bugs.python.org (Nir Aides)
Date: Mon, 16 May 2011 18:57:30 +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: <1305572250.09.0.136537638335.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Steffen, can you explain in layman's terms?

On Sun, May 15, 2011 at 8:03 PM, Steffen Daode Nurpmeso <report at bugs.python.org> wrote:
>
> @ Charles-Fran?ois Natali wrote (2011-05-15 01:14+0200):
>> So if we really wanted to be safe, the only solution would be to
>> forbid fork() in a multi-threaded program.
>> Since it's not really a reasonable option
>
> But now - why this?  The only really acceptable thing if you have
> control about what you are doing is the following:
>
> class SMP::Process
>    /*!
>    * \brief Daemonize process.
>    *[.]
>    * \note
>    * The implementation of this function is not trivial.
>    * To avoid portability no-goes and other such problems,
>    * you may \e not call this function after you have initialized
>    * Thread::enableSMP(),
>    * nor may there (have) be(en) Child objects,
>    * nor may you have used an EventLoop!
>    * I.e., the process has to be a single threaded, "synchronous" one.
>    * [.]
>    */
>    pub static si32 daemonize(ui32 _daemon_flags=df_default);
>
> namespace SMP::POSIX
>    /*!
>    * \brief \fn fork(2).
>    *[.]
>    * Be aware that this passes by all \SMP and Child related code,
>    * i.e., this simply \e is the system-call.
>    * Signal::resetAllSignalStates() and Child::killAll() are thus if
>    * particular interest; thread handling is still entirely up to you.
>    */
>    pub static sir fork(void);
>
> Which kind of programs cannot be written with this restriction?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Mon May 16 20:59:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 16 May 2011 18:59:48 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1305572388.92.0.653201394522.issue11986@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

rhettinger> Your other tracker item correctly focused on the behavior of
rhettinger> float('NaN') itself,

You closed issue11949 as well, so it won't help.  I disagree that this issue would be resolved by resolving issue11949.  Defining max(nan, x) and nan < x are two different issues.  Quoting Kahan,

"""
Some familiar functions have yet to be defined for NaN . For instance max{x, y} should deliver the same result as max{y, x} but almost no implementations do that when x is NaN . There are good reasons to define max{NaN, 5} := max{5, NaN} := 5 though many would disagree.
"""
-- Lecture Notes on the Status of IEEE Standard 754 for Binary
Floating-Point Arithmetic by Prof. W. Kahan
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps

In the same lecture, Prof. Kahan states that nan < x must signal.

My ideal solution would be to make nan < x signal, keep naive implementation of builtin max() and provide symmetric float.max such that nan.max(x) = x.max(nan) = x (nan result would be a valid but less useful alternative.)

This will make float behavior closer to that of Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Mon May 16 21:24:33 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 16 May 2011 19:24:33 +0000
Subject: [issue12018] No tests for ntpath.samefile, ntpath.sameopenfile
In-Reply-To: <1304694770.94.0.722245311346.issue12018@psf.upfronthosting.co.za>
Message-ID: <1305573873.07.0.54522462954.issue12018@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy:  -sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12018>
_______________________________________

From report at bugs.python.org  Mon May 16 21:35:45 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 16 May 2011 19:35:45 +0000
Subject: [issue12045] external shell command executed twice in
	ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <1305574545.85.0.825641613012.issue12045@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy:  -sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Mon May 16 21:39:44 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 16 May 2011 19:39:44 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1305574784.43.0.647291350232.issue11882@psf.upfronthosting.co.za>


Changes by Sijin Joseph <sijinjoseph at gmail.com>:


----------
nosy:  -sijinjoseph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Mon May 16 21:45:53 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 16 May 2011 19:45:53 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305575153.83.0.218394781808.issue12084@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/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 16 21:52:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 16 May 2011 19:52:31 +0000
Subject: [issue12091] multiprocessing: simplify ApplyResult and MapResult with
	threading.Event
In-Reply-To: <1305575550.96.0.535779831013.issue12091@psf.upfronthosting.co.za>
Message-ID: <1305575550.96.0.535779831013.issue12091@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Multiprocessing's MapResult and ApplyResult use a notification mechanism to signal callers when the underlying value is available.
Instead of re-inventing the wheel, we could use threading.Event instead: this leads to cleaner and simpler code (with no noticable performance impact).
Patch attached.

----------
components: Library (Lib)
files: multiprocessing_event.diff
keywords: patch
messages: 136122
nosy: asksol, jnoller, neologix
priority: low
severity: normal
stage: patch review
status: open
title: multiprocessing: simplify ApplyResult and MapResult with threading.Event
type: behavior
Added file: http://bugs.python.org/file22009/multiprocessing_event.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12091>
_______________________________________

From report at bugs.python.org  Mon May 16 22:00:32 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 16 May 2011 20:00:32 +0000
Subject: [issue12034] check_GetFinalPathNameByHandle() suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1305576032.49.0.286407946553.issue12034@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Is this related to some other issue? The fix seems trivial, however I am curious as to how you stumbled upon this?

Is there more to this issue than just performance?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12034>
_______________________________________

From report at bugs.python.org  Mon May 16 22:02:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 May 2011 20:02:59 +0000
Subject: [issue12034] check_GetFinalPathNameByHandle() suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1305576179.41.0.232396619028.issue12034@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, it should be trivial to fix.
I've stumbled on this simply because I needed to write similar code for another patch, so studied how it was done in posixmodule.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12034>
_______________________________________

From report at bugs.python.org  Mon May 16 22:14:39 2011
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 16 May 2011 20:14:39 +0000
Subject: [issue12045] external shell command executed twice in
	ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <1305576879.97.0.458387302894.issue12045@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Attaching patch.

Removed the second call to os.popen and used the dump variable that was read earlier as the argument to re.search.

----------
keywords: +patch
nosy: +sijinjoseph
Added file: http://bugs.python.org/file22010/12045.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Mon May 16 22:36:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 16 May 2011 20:36:56 +0000
Subject: [issue10239] multiprocessing signal defect
In-Reply-To: <1288394215.77.0.548546453829.issue10239@psf.upfronthosting.co.za>
Message-ID: <1305578216.76.0.658196981528.issue10239@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Closing as duplicate of issue #9205.

----------
nosy: +neologix
resolution:  -> duplicate
status: open -> closed
superseder:  -> Parent process hanging in multiprocessing if children terminate unexpectedly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10239>
_______________________________________

From report at bugs.python.org  Mon May 16 23:07:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 16 May 2011 21:07:50 +0000
Subject: [issue1615158] POSIX capabilities support
In-Reply-To: <1305556726.81.0.907941336796.issue1615158@psf.upfronthosting.co.za>
Message-ID: <4DD19224.2080300@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> "posixcap" sounds ok to me.

Bike-sheddingly, it bothers me that these functions are actually
*not* defined by POSIX, but have been withdrawn before becoming
standard. So I'd rather call it linuxcap. Using _linuxcap, and
exposing them from os sounds fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615158>
_______________________________________

From report at bugs.python.org  Mon May 16 23:50:21 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 16 May 2011 21:50:21 +0000
Subject: [issue12092] Clarify sentence in tutorial
In-Reply-To: <1305582621.21.0.962963966235.issue12092@psf.upfronthosting.co.za>
Message-ID: <1305582621.21.0.962963966235.issue12092@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

following up http://mail.python.org/pipermail/docs/2011-April/004161.html, it would be nice to have changeset 1811eb03ba00 applied in 2.7 (it's already there in 3.1, 3.2 and default). Added Georg to the nosy list since it's the author of the given cs.

----------
assignee: docs at python
components: Documentation
keywords: patch
messages: 136128
nosy: docs at python, georg.brandl, sandro.tosi
priority: normal
severity: normal
stage: commit review
status: open
title: Clarify sentence in tutorial
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12092>
_______________________________________

From report at bugs.python.org  Tue May 17 00:22:58 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 16 May 2011 22:22:58 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1305584578.64.0.563453520984.issue7443@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/issue7443>
_______________________________________

From report at bugs.python.org  Tue May 17 00:36:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 16 May 2011 22:36:11 +0000
Subject: [issue12093] Typo in struct unpacking example
In-Reply-To: <1305585371.59.0.443162933344.issue12093@psf.upfronthosting.co.za>
Message-ID: <1305585371.59.0.443162933344.issue12093@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

following up http://mail.python.org/pipermail/docs/2011-April/004154.html and what was done in 1de718a31004, here's a tiny patch to correct that typo in 2.7 too.

----------
assignee: docs at python
components: Documentation
files: struct_unpack_record.patch
keywords: patch
messages: 136129
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Typo in struct unpacking example
versions: Python 2.7
Added file: http://bugs.python.org/file22011/struct_unpack_record.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12093>
_______________________________________

From report at bugs.python.org  Tue May 17 01:06:02 2011
From: report at bugs.python.org (Nathan)
Date: Mon, 16 May 2011 23:06:02 +0000
Subject: [issue12094] Cannot Launch IDLE
In-Reply-To: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>
Message-ID: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>


New submission from Nathan <nathaniel.j.buck at gmail.com>:

To Whom it may concern ? I have suddenly lost my ability to launch IDLE.  I am using 2.6 with windows xp.  I was using ipython with PyReadline.  I have uninstalled and reinstalled just python 2.6.6 with no luck.

I get the following error:

Thanks in advance 

C:\Python26>python.exe Lib\idlelib\idle.py
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 6, in <module>
    import PyShell
  File "C:\Python26\Lib\idlelib\PyShell.py", line 3, in <module>
    import os
  File "C:\Python26\lib\os.py", line 398, in <module>
    import UserDict
  File "C:\Python26\lib\UserDict.py", line 82, in <module>
    import _abcoll
  File "C:\Python26\lib\_abcoll.py", line 11, in <module>
    from abc import ABCMeta, abstractmethod
ImportError: cannot import name ABCMeta

----------
components: IDLE
messages: 136130
nosy: nbuck
priority: normal
severity: normal
status: open
title: Cannot Launch IDLE
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12094>
_______________________________________

From report at bugs.python.org  Tue May 17 01:19:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2011 23:19:24 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <E1QM74G-0000KB-8M@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 47bc3509f76b by Victor Stinner in branch '2.7':
Issue #11614: Fix test_linecache, cjkencodings_test.py doesn't exist anymore
http://hg.python.org/cpython/rev/47bc3509f76b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Tue May 17 02:57:59 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 17 May 2011 00:57:59 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305593879.3.0.365804831804.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Looks like I was referring to a different patch from the email - sorry for any confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue May 17 03:55:16 2011
From: report at bugs.python.org (=?utf-8?b?UmVuw6kgU2Now7xtYW5u?=)
Date: Tue, 17 May 2011 01:55:16 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1305597316.91.0.0874787280785.issue1006238@psf.upfronthosting.co.za>


Changes by Ren? Sch?mann <whitetigx at gmail.com>:


----------
nosy: +WhiteTiger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Tue May 17 03:55:32 2011
From: report at bugs.python.org (=?utf-8?b?UmVuw6kgU2Now7xtYW5u?=)
Date: Tue, 17 May 2011 01:55:32 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1305597332.14.0.737997507296.issue4709@psf.upfronthosting.co.za>


Changes by Ren? Sch?mann <whitetigx at gmail.com>:


----------
nosy: +WhiteTiger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Tue May 17 03:58:38 2011
From: report at bugs.python.org (=?utf-8?b?UmVuw6kgU2Now7xtYW5u?=)
Date: Tue, 17 May 2011 01:58:38 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1305597518.66.0.102283164875.issue3754@psf.upfronthosting.co.za>


Changes by Ren? Sch?mann <whitetigx at gmail.com>:


----------
nosy: +WhiteTiger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Tue May 17 04:04:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 May 2011 02:04:17 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305597857.35.0.748554078232.issue12086@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: lukasz.langa -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Tue May 17 04:06:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 May 2011 02:06:51 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305598011.85.0.540799690862.issue12086@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This is a venerable section of the tutorial that has been exposed to many, many readers and AFAICT it has never caused a problem.  So, I see no need to make a change to it.

Also as Georg points out, the docs (especially the tutorial) are not about discouragement, they are about empowerment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Tue May 17 04:08:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 May 2011 02:08:01 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1305598081.46.0.178234045873.issue12077@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Tue May 17 04:12:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 May 2011 02:12:08 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1305598328.45.0.546120281089.issue12028@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Tue May 17 04:13:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 May 2011 02:13:53 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1305598433.99.0.140453655573.issue11986@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Tue May 17 04:14:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 02:14:36 +0000
Subject: [issue12088] tarfile.extractall fails to overwrite unresolved
	symlinks and hard links
In-Reply-To: <1305554464.99.0.852518621485.issue12088@psf.upfronthosting.co.za>
Message-ID: <E1QM9nu-0003EX-Ua@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b29f0b6fcb76 by Senthil Kumaran in branch '2.7':
Fix closes issue #12088 - fixes the tarfile.extractall  issue when the
http://hg.python.org/cpython/rev/b29f0b6fcb76

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12088>
_______________________________________

From report at bugs.python.org  Tue May 17 04:16:01 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 17 May 2011 02:16:01 +0000
Subject: [issue12088] tarfile.extractall fails to overwrite unresolved
	symlinks and hard links
In-Reply-To: <1305554464.99.0.852518621485.issue12088@psf.upfronthosting.co.za>
Message-ID: <1305598561.74.0.070787615488.issue12088@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Committed the fix. Thank you, Scott.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12088>
_______________________________________

From report at bugs.python.org  Tue May 17 04:18:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 02:18:43 +0000
Subject: [issue12093] Typo in struct unpacking example
In-Reply-To: <1305585371.59.0.443162933344.issue12093@psf.upfronthosting.co.za>
Message-ID: <E1QM9ru-0003Xy-67@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 874309ce6e62 by Ezio Melotti in branch '2.7':
#12093: fix typo in struct doc. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/874309ce6e62

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12093>
_______________________________________

From report at bugs.python.org  Tue May 17 04:19:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 May 2011 02:19:55 +0000
Subject: [issue12093] Typo in struct unpacking example
In-Reply-To: <1305585371.59.0.443162933344.issue12093@psf.upfronthosting.co.za>
Message-ID: <1305598795.04.0.662260755463.issue12093@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12093>
_______________________________________

From report at bugs.python.org  Tue May 17 04:39:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 02:39:34 +0000
Subject: [issue12092] Clarify sentence in tutorial
In-Reply-To: <1305582621.21.0.962963966235.issue12092@psf.upfronthosting.co.za>
Message-ID: <E1QMAC5-0004l1-AK@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c449d3c3e0da by Ezio Melotti in branch '2.7':
#12092: backport rephrasing of a paragraph in the tutorial.
http://hg.python.org/cpython/rev/c449d3c3e0da

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12092>
_______________________________________

From report at bugs.python.org  Tue May 17 04:40:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 May 2011 02:40:11 +0000
Subject: [issue12092] Clarify sentence in tutorial
In-Reply-To: <1305582621.21.0.962963966235.issue12092@psf.upfronthosting.co.za>
Message-ID: <1305600011.3.0.869093001254.issue12092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12092>
_______________________________________

From report at bugs.python.org  Tue May 17 05:11:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 May 2011 03:11:15 +0000
Subject: [issue12094] Cannot Launch IDLE
In-Reply-To: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>
Message-ID: <1305601875.86.0.0476094955049.issue12094@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I can't test this on Windows, but you could try the following things:
  1) check that 'python.exe -V' returns 2.6.6;
  2) try using the IDLE shortcut in the start menu;
  3) try "from abc import ABCMeta" from the interactive interpreter;
  4) install Python 2.7 and see if it works there.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12094>
_______________________________________

From report at bugs.python.org  Tue May 17 05:12:06 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 17 May 2011 03:12:06 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305601926.6.0.662940869992.issue12084@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
Removed message: http://bugs.python.org/msg136132

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue May 17 05:18:47 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 17 May 2011 03:18:47 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1305602327.99.0.417667303394.issue11197@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/issue11197>
_______________________________________

From report at bugs.python.org  Tue May 17 06:33:07 2011
From: report at bugs.python.org (Takeshi Yoshino)
Date: Tue, 17 May 2011 04:33:07 +0000
Subject: [issue12050] unconsumed_tail of zlib.Decompress is not always cleared
	on decompress() call
In-Reply-To: <1305024254.99.0.898091507318.issue12050@psf.upfronthosting.co.za>
Message-ID: <1305606787.14.0.560310305742.issue12050@psf.upfronthosting.co.za>


Takeshi Yoshino <tyoshino at google.com> added the comment:

Thank you for the fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12050>
_______________________________________

From report at bugs.python.org  Tue May 17 07:16:58 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 17 May 2011 05:16:58 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1305609418.44.0.620614580103.issue12077@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/issue12077>
_______________________________________

From report at bugs.python.org  Tue May 17 07:40:12 2011
From: report at bugs.python.org (David Coles)
Date: Tue, 17 May 2011 05:40:12 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1305610812.63.0.150770463821.issue12010@psf.upfronthosting.co.za>


David Coles <coles.david at gmail.com> added the comment:

Attached is a patch that updates configure.in to make sure that wchar.h is present and that wchar_t is at least 16 bits wide.

On android-8 this patch causes the configure step to fail since SIZEOF_WCHAR_T == 1. On android-9 and my Linux desktop the build continues as normal, passing the build tests. If wchar.h is removed from the system then the build also fails with an error as expected.

The patch does not contain the configure diff since it also contained some other changes and I wasn't sure of the correct autoreconf process for Python.

----------
keywords: +patch
Added file: http://bugs.python.org/file22012/wchar_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Tue May 17 09:16:53 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 17 May 2011 07:16:53 +0000
Subject: [issue12094] Cannot Launch IDLE
In-Reply-To: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>
Message-ID: <1305616613.44.0.19322796395.issue12094@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Maybe you have created a file named "abc.py" somewhere?
What happens when you type:

C:\Python26>python.exe -c "import abc; print abc"

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12094>
_______________________________________

From report at bugs.python.org  Tue May 17 10:07:56 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 17 May 2011 08:07:56 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1305619676.6.0.696576032368.issue4709@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I'm also using this patch successfully (together with http://tdm-gcc.tdragon.net/).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Tue May 17 11:16:50 2011
From: report at bugs.python.org (Radomir Dopieralski)
Date: Tue, 17 May 2011 09:16:50 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305623810.06.0.242144878193.issue12086@psf.upfronthosting.co.za>


Radomir Dopieralski <python-bugs at sheep.art.pl> added the comment:

I am reporting this specifically because I just had two independent cases of people who submitted code that had almost all methods name-mangled (within 2 weeks), and who then pointed to that section of the tutorial as justification. I have a hard time convincing them that it is a bad idea, as I have to work against the official documentation here. 

I agree that the language and library references should explain the mechanics behind the language in a neutral and empowering way. But I think that tutorial shouldn't tell people to write horrible code.

Perhaps it would suffice if the tutorial didn't call this "private methods"? A more descriptive and accurate section name, such as "name mangling" or "avoiding name clashes" could help a lot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Tue May 17 12:33:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 May 2011 10:33:46 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1305628426.66.0.0687617512452.issue12086@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW that section used to be called "Private variables through name mangling" back in 1.5, and started by saying "There is now limited support for class-private identifiers.".

PEP8 [0] also talks about the name mangling in several places, and carefully avoids the use of "private":
  """
  To avoid name clashes with subclasses, use two leading underscores to
  invoke Python's name mangling rules.

  Python mangles these names with the class name: if class Foo has an
  attribute named __a, it cannot be accessed by Foo.__a.  (An insistent
  user could still gain access by calling Foo._Foo__a.) Generally, double
  leading underscores should be used only to avoid name conflicts with
  attributes in classes designed to be subclassed.
  """

And it even includes the following two notes:
  """
  We don't use the term "private" here, since no attribute is really
  private in Python (without a generally unnecessary amount of work).
  """

  """
  Not everyone likes name mangling.  Try to balance the
  need to avoid accidental name clashes with potential use by
  advanced callers.
  """

[0]: http://www.python.org/dev/peps/pep-0008/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12086>
_______________________________________

From report at bugs.python.org  Tue May 17 12:35:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 17 May 2011 10:35:25 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1305572250.09.0.136537638335.issue6721@psf.upfronthosting.co.za>
Message-ID: <20110517103517.GA82726@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@ Nir Aides wrote (2011-05-16 20:57+0200):
> Steffen, can you explain in layman's terms?

I am the layman here.
Charles-Fran?ois has written a patch for Python which contradicted
his own proposal from msg135079, but he seems to have tested a lot
so that he then was even able to prove that his own proposal was
correct.  His new patch does implement that with a nice
introductional note.

He has also noticed that the only really safe solution is to
simply disallow multi-threading in programs which fork().  And
this either-or is exactly the conclusion we have taken and
implemented in our C++ library - which is not an embeddable
programming language that needs to integrate nicely in whatever
environment it is thrown into, but "even replaces main()".
And i don't know any application which cannot be implemented
regardless of fork()-or-threads instead of fork()-and-threads.
(You *can* have fork()+exec()-and-threads at any time!)

So what i tried to say is that it is extremely error-prone and
resource intensive to try to implement anything that tries to
achieve both.  I.e. on Solaris they do have a forkall() and it
seems they have atfork handlers for everything (and even document
that in the system manual).  atfork handlers for everything!!
And for what?  To implement a standart which is obviously
brain-dead because it is *impossible* to handle it - as your link
has shown this is even confessed by members of the committee.

And writing memory in the child causes page-faults.
That's all i wanted to say.
(Writing this mail required more than 20 minutes, the mentioned
one was out in less than one.  And it is much more meaningful
AFAIK.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Tue May 17 13:27:58 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 11:27:58 +0000
Subject: [issue12095] test failures due to missing module
In-Reply-To: <1305631678.63.0.570851532956.issue12095@psf.upfronthosting.co.za>
Message-ID: <1305631678.63.0.570851532956.issue12095@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

When I run the test suite on OSX (configure; make test) I get unexpected est failures:

6 tests failed:
    test_codecencodings_cn test_codecencodings_hk
    test_codecencodings_jp test_codecencodings_kr
    test_codecencodings_tw

When I run one of these manually I get the following traceback:


./python.exe ../Lib/test/test_codecencodings_cn.py
Traceback (most recent call last):
  File "../Lib/test/test_codecencodings_cn.py", line 11, in <module>
    class Test_GB2312(test_multibytecodec_support.TestBase, unittest.TestCase):
  File "../Lib/test/test_codecencodings_cn.py", line 13, in Test_GB2312
    tstring = test_multibytecodec_support.load_teststring('gb2312')
  File "/Users/ronald/Projects/python/rw/2.7/Lib/test/test_multibytecodec_support.py", line 330, in load_teststring
    from test import cjkencodings_test
ImportError: cannot import name cjkencodings_test


The only reference to cjkencodings_test in the entire 2.7 tree is this import line, there is no module or extension with this name.

----------
components: Library (Lib)
messages: 136148
nosy: ronaldoussoren
priority: high
severity: normal
status: open
title: test failures due to missing module
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12095>
_______________________________________

From report at bugs.python.org  Tue May 17 13:33:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 May 2011 11:33:32 +0000
Subject: [issue12095] test failures due to missing module
In-Reply-To: <1305631678.63.0.570851532956.issue12095@psf.upfronthosting.co.za>
Message-ID: <1305632012.26.0.31332841981.issue12095@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/issue12095>
_______________________________________

From report at bugs.python.org  Tue May 17 14:09:56 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 12:09:56 +0000
Subject: [issue12095] test failures due to missing module
In-Reply-To: <1305631678.63.0.570851532956.issue12095@psf.upfronthosting.co.za>
Message-ID: <1305634196.3.0.899933094084.issue12095@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've verified the issue in a fresh download of revision c449d3c3e0da of the 2.7 branch.

I'm on OSX 10.6, but that's not really relevant for this issue.

If I'm using 'hg bisect' correctly (and that's a big if as I haven't used it before) this failure is caused by this patch:

The first bad revision is:
changeset:   70161:1bd697cdd210
branch:      2.7
parent:      70145:978016199be8
user:        Victor Stinner <victor.stinner at haypocalc.com>
date:        Mon May 16 17:16:18 2011 +0200
summary:     Issue #12057: Convert CJK encoding testcase BLOB into multiple text files


And indeed in this revision:

$ ls cjkencodings_test.py 
ls: cjkencodings_test.py: No such file or directory

$ grep cjkencodings_test test_multibytecodec_support.py
    from test import cjkencodings_test
    return cjkencodings_test.teststring[encoding]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12095>
_______________________________________

From report at bugs.python.org  Tue May 17 14:10:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 12:10:13 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <E1QMJ6J-0006dL-NM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 932de36903e7 by Ronald Oussoren in branch '2.7':
(backport)Fix #10154 and #10090: locale normalizes the UTF-8 encoding to "UTF-8" instead of "UTF8"
http://hg.python.org/cpython/rev/932de36903e7

New changeset 28e410eb86af by Ronald Oussoren in branch '3.1':
Fix #10154 and #10090: locale normalizes the UTF-8 encoding to "UTF-8" instead of "UTF8"
http://hg.python.org/cpython/rev/28e410eb86af

New changeset 454d13e535ff by Ronald Oussoren in branch '3.2':
(merge) Fix #10154 and #10090: locale normalizes the UTF-8 encoding to "UTF-8" instead of "UTF8"
http://hg.python.org/cpython/rev/454d13e535ff

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Tue May 17 14:14:03 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 12:14:03 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1305634443.53.0.117516162526.issue10154@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Tue May 17 14:14:26 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 12:14:26 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1305634466.26.0.941875691557.issue10154@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Tue May 17 14:15:25 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 12:15:25 +0000
Subject: [issue10090] python -m locale fails on OSX
In-Reply-To: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>
Message-ID: <1305634525.95.0.733454183042.issue10090@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied a fix for #10154 and that also fixes this problem.

----------
nosy: +ronaldoussoren
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10090>
_______________________________________

From report at bugs.python.org  Tue May 17 14:32:16 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 12:32:16 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1305635536.6.0.686354490068.issue9811@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've filed #9451707 about this in Apple's bug tracker.

BTW. I don't think this is a platform bug, neither the manpage nor the unix specification at <http://pubs.opengroup.org/onlinepubs/007908799/xsh/strftime.html> specify what happens when you use an undocumented format specifier.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Tue May 17 14:49:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 12:49:51 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <E1QMJig-0001a1-GG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3d7cb852a176 by Ronald Oussoren in branch 'default':
Fix for issue 10154, merge from 3.2
http://hg.python.org/cpython/rev/3d7cb852a176

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Tue May 17 14:49:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 12:49:51 +0000
Subject: [issue11088] IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input
	/ raw_input
In-Reply-To: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>
Message-ID: <E1QMJig-0001a1-Fw@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1c6823317a06 by Ronald Oussoren in branch '3.2':
Fixes #11088: IDLE crashes when using F5 to run a script on OSX with Tk 8.5
http://hg.python.org/cpython/rev/1c6823317a06

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11088>
_______________________________________

From report at bugs.python.org  Tue May 17 14:52:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 12:52:49 +0000
Subject: [issue11088] IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input
	/ raw_input
In-Reply-To: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>
Message-ID: <E1QMJlX-0001xG-Qa@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 85aa02bc674c by Ronald Oussoren in branch 'default':
Fixes #11088: IDLE crashes when using F5 to run a script on OSX with Tk 8.5
http://hg.python.org/cpython/rev/85aa02bc674c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11088>
_______________________________________

From report at bugs.python.org  Tue May 17 15:13:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 13:13:56 +0000
Subject: [issue11088] IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input
	/ raw_input
In-Reply-To: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>
Message-ID: <E1QMK5z-0003kM-Bg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 578020fe2875 by Ronald Oussoren in branch '2.7':
(backport) Fixes #11088: IDLE crashes when using F5 to run a script on OSX with Tk 8.5
http://hg.python.org/cpython/rev/578020fe2875

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11088>
_______________________________________

From report at bugs.python.org  Tue May 17 15:14:46 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 13:14:46 +0000
Subject: [issue11088] IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input
	/ raw_input
In-Reply-To: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>
Message-ID: <1305638086.64.0.492328575784.issue11088@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't really like this patch, but like crashes that cause data loss even less...

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11088>
_______________________________________

From report at bugs.python.org  Tue May 17 15:49:33 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 17 May 2011 13:49:33 +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: <20110517134922.GA31090@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Thank you, thank you, thank you.
I'm a bit irritated that a french man treats a "wet-her" as a typo!
What if *i* like it??  In fact it is a fantastic physical backing
store.  Unbeatable.

Well and about dropping the fsync() in case the fcntl() fails with
ENOTTY.  This is "<Esc>2dd", which shouldn't hurt a committer.
I'm convinced that full_fsync=False is optional and false by
default, but i don't trust Apple.  I've seen a reference to an
"atomic file" somewhere on bugs.python.org and that does fsync()
first followed by fcntl() if FULLFSYNC is available.  Thus, if
someone knows about that, she may do so, but otherwise i would
guess he doesn't, and in that case i would not expect ENOTTY from
an fsync() - still i want a full flush!
This is what NetBSD describes:

NOTES
    For optimal efficiency, the fsync_range() call requires that
    the file system containing the file referenced by fd support
    partial synchronization of file data.  For file systems which
    do not support partial synchronization, the entire file will
    be synchronized and the call will be the equivalent of calling
    fsync().

But Apple is *soooo*speeeeciaaaal* again.  Happy birthday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue May 17 15:50:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 13:50:17 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QMKfA-0007Em-5Z@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 83f4c270b27d by Victor Stinner in branch '2.7':
Issue #12057: Fix .hgeol and test_multibytecodec_support for the conversion of
http://hg.python.org/cpython/rev/83f4c270b27d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Tue May 17 15:52:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 13:52:20 +0000
Subject: [issue12095] test failures due to missing module
In-Reply-To: <1305631678.63.0.570851532956.issue12095@psf.upfronthosting.co.za>
Message-ID: <1305640340.37.0.704025989292.issue12095@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh oh. I forgot to patch .hgeol and test_multibytecodec_support.py during my "merge" 3.1 (16503022c4b8) -> 2.7 (1bd697cdd210). It should be ok with 83f4c270b27d.

Thank you for your report Ronald.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12095>
_______________________________________

From report at bugs.python.org  Tue May 17 16:06:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2011 14:06:27 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1305641187.84.0.87762230449.issue9811@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Right, that's why I said "if it is a bug" :)

FreeBSD has the same behavior, so I'd actually prefer that Apple not "fix" this.  It would be nice if FreeBSD did and Apple adopted it, though, since only dropping the % is the least intuitive approach to handling unknown codes I can think of.  Is Apple tracking FreeBSD development at all these days, or are they a true fork now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Tue May 17 16:08:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 May 2011 14:08:43 +0000
Subject: [issue12091] multiprocessing: simplify ApplyResult and MapResult with
	threading.Event
In-Reply-To: <1305575550.96.0.535779831013.issue12091@psf.upfronthosting.co.za>
Message-ID: <1305641323.57.0.0808460342396.issue12091@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/issue12091>
_______________________________________

From report at bugs.python.org  Tue May 17 16:38:11 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Tue, 17 May 2011 14:38:11 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1305643091.11.0.0359473489738.issue12009@psf.upfronthosting.co.za>


Ruslan Mstoi <rmstoi at gmail.com> added the comment:

OK, finally got some time to make a patch. The fix is to seek the beginning of the comment before calling readline. That way the next line won't be deleted.

Also, provided a test case for this issue in the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file22013/issue12009_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Tue May 17 16:52:48 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 14:52:48 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1305643968.0.0.963385463942.issue9811@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm not sure if Apple's tracking FreeBSD, but they at the very least heavily borrow code (see <http://opensource.apple.com/source/Libc/Libc-594.9.4/> for libc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Tue May 17 17:22:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 15:22:55 +0000
Subject: [issue12096] test_threading.test_waitfor() timeout (1 hour) on x86
	Gentoo 3.x buildbot
In-Reply-To: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>
Message-ID: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Builder x86 Gentoo 3.x Build #130:

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/130/steps/test/logs/stdio

[263/354] test_threading
Timeout (1:00:00)!
Thread 0x48f0bb70:
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/threading.py", line 237 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/threading.py", line 278 in wait_for
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 472 in f
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 37 in task

Thread 0x401aa010:
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 16 in _wait
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 51 in wait_for_finished
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/lock_tests.py", line 482 in test_waitfor
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 407 in _executeTestPart
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 462 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/case.py", line 514 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 105 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 105 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/unittest/suite.py", line 67 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/support.py", line 1096 in run
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/support.py", line 1184 in _run_suite
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/support.py", line 1210 in run_unittest
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_threading.py", line 743 in test_main
  File "./Lib/test/regrtest.py", line 1044 in runtest_inner
  File "./Lib/test/regrtest.py", line 838 in runtest
  File "./Lib/test/regrtest.py", line 662 in main
  File "./Lib/test/regrtest.py", line 1622 in <module>

----------
components: Library (Lib)
messages: 136164
nosy: haypo
priority: normal
severity: normal
status: open
title: test_threading.test_waitfor() timeout (1 hour) on x86 Gentoo 3.x buildbot
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12096>
_______________________________________

From report at bugs.python.org  Tue May 17 17:37:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 17 May 2011 15:37:01 +0000
Subject: [issue12096] test_threading.test_waitfor() timeout (1 hour) on x86
	Gentoo 3.x buildbot
In-Reply-To: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>
Message-ID: <1305646621.43.0.771546630148.issue12096@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The sleep is too short:

       def f():
           with cond:
               result = cond.wait_for(lambda : state==4)


      for i in range(5):
          time.sleep(0.01)
          with cond:
          state += 1
          cond.notify()


If state is incremented to 5 before the thread waits on the condition, it's going to wait forever (it can be reproduced easily by removing the sleep).
We could either increase the sleep, or change the predicate to state==5.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12096>
_______________________________________

From report at bugs.python.org  Tue May 17 17:43:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 17 May 2011 15:43:42 +0000
Subject: [issue6059] ctypes/uuid-related segmentation fault
In-Reply-To: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>
Message-ID: <1305647022.87.0.986192229109.issue6059@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's probably a libc buc, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453

Basically, when libraries are dynamically loaded in an interleaved way, this can lead to TLS being returned uninitialized, hence leading to a segfault upon access.
A fix has been committed really recently.

If I'm correct, importing uuid first should do the trick.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6059>
_______________________________________

From report at bugs.python.org  Tue May 17 17:51:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2011 15:51:36 +0000
Subject: [issue12096] test_threading.test_waitfor() timeout (1 hour) on x86
	Gentoo 3.x buildbot
In-Reply-To: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>
Message-ID: <1305647496.69.0.524229404665.issue12096@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +buildbot
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12096>
_______________________________________

From report at bugs.python.org  Tue May 17 17:56:52 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 May 2011 15:56:52 +0000
Subject: [issue11486] Add option to not install into /Applications
In-Reply-To: <1300051941.49.0.427500618783.issue11486@psf.upfronthosting.co.za>
Message-ID: <1305647812.1.0.00985550589974.issue11486@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This patch adds an flag to the configure script: --without-framework-applications.

When this flag is used 'make install' will not create /Applications/Python 3.3, and won't install IDLE.app and PythonLauncher.app

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22014/issue11486.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11486>
_______________________________________

From report at bugs.python.org  Tue May 17 18:28:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2011 16:28:52 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1305649732.74.0.346850799182.issue12009@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Tue May 17 19:04:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2011 17:04:07 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1305651847.94.0.968134180187.issue12009@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

With these new additions, the test input is getting unwieldy.  If you have the time, I'd like to see the unit tests refactored to be more unit-testy.  That is, instead of a single test netrc file, have multiple inputs, one for each thing being tested, and turn setUp into a factory function that each test calls:

      def make_nrc (self, test_data):
        mode = 'w'
        if sys.platform not in ['cygwin']:
            mode += 't'
        fp = open(temp_filename, mode)
        fp.write(test_data)
        fp.close()
        return netrc.netrc(temp_filename)

You can also use textwrap.dedent to embed the test_string in the call to make_nrc in the test method in a pretty fashion:

      def test_default_login(self):
        nrc = self.make_nrc(textwrap.dedent("""\
            default login log2 password pass2
            """)
        self.assertEqual(self.nrc.hosts['default'], ('log2', None, 'pass2'))

If you don't have time to do this I'll do it at some point (not sure when).

I haven't looked at your fix in detail because the unit tests don't currently isolate the issues, but it looks to like it is the right approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Tue May 17 19:21:52 2011
From: report at bugs.python.org (Nathan)
Date: Tue, 17 May 2011 17:21:52 +0000
Subject: [issue12094] Cannot Launch IDLE
In-Reply-To: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>
Message-ID: <1305652912.67.0.219322452049.issue12094@psf.upfronthosting.co.za>


Nathan <nathaniel.j.buck at gmail.com> added the comment:

Thanks for the speedy reply I have cut and past the results from the for following tests

I can't test this on Windows, but you could try the following things:
  1) check that 'python.exe -V' returns 2.6.6;
  2) try using the IDLE shortcut in the start menu;
  3) try "from abc import ABCMeta" from the interactive interpreter;
  4) install Python 2.7 and see if it works there.


1) C:\Documents and Settings\buck>python.exe -V
   Python 2.6.6

2.) Does not open from the start menu

3.) C:\Documents and Settings\buck>python
    'import site' failed; use -v for traceback
     Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSCv.1500
     32 bit (Intel)] on win32
     Type "help", "copyright", "credits" or "license" for 
     more information.
     >>> from abc import ABCMeta
     Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     ImportError: cannot import name ABCMeta

4.)  C:\Python27>python.exe Lib\idlelib\idle.py
Traceback (most recent call last):
  File "C:\Python27\lib\site.py", line 62, in <module>
    import os
  File "C:\Python27\lib\os.py", line 398, in <module>
    import UserDict
  File "C:\Python27\lib\UserDict.py", line 83, in <module>
    import _abcoll
  File "C:\Python27\lib\_abcoll.py", line 11, in <module>
    from abc import ABCMeta, abstractmethod
ImportError: cannot import name ABCMeta

Lastly

C:\Python26>python.exe -c "import abc; print abc"
'import site' failed; use -v for traceback
<module 'abc' from 'C:\w\ADCP_programs\abc.py'>

Thanks again

Nathan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12094>
_______________________________________

From report at bugs.python.org  Tue May 17 19:26:52 2011
From: report at bugs.python.org (Nathan)
Date: Tue, 17 May 2011 17:26:52 +0000
Subject: [issue12094] Cannot Launch IDLE
In-Reply-To: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>
Message-ID: <1305653212.91.0.437057541671.issue12094@psf.upfronthosting.co.za>


Nathan <nathaniel.j.buck at gmail.com> added the comment:

So obviously the abc.py is already a module in the the frame work! 

All fixed 

Thanks again

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12094>
_______________________________________

From report at bugs.python.org  Tue May 17 19:31:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 17 May 2011 17:31:38 +0000
Subject: [issue12096] test_threading.test_waitfor() timeout (1 hour) on x86
	Gentoo 3.x buildbot
In-Reply-To: <1305647496.74.0.811499615634.issue12096@psf.upfronthosting.co.za>
Message-ID: <BANLkTik79_kZqUqVGBtvWfonBLhugaew+g@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

Here's a one-liner patch using the later approach  (that way we're
sure the test won't hang).

----------
keywords: +patch
Added file: http://bugs.python.org/file22015/wait_for_race.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12096>
_______________________________________
-------------- next part --------------
diff -r 85aa02bc674c Lib/test/lock_tests.py
--- a/Lib/test/lock_tests.py	Tue May 17 14:52:21 2011 +0200
+++ b/Lib/test/lock_tests.py	Tue May 17 19:21:59 2011 +0200
@@ -474,7 +474,7 @@
                 self.assertEqual(state, 4)
         b = Bunch(f, 1)
         b.wait_for_started()
-        for i in range(5):
+        for i in range(4):
             time.sleep(0.01)
             with cond:
                 state += 1

From report at bugs.python.org  Tue May 17 19:35:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 17 May 2011 17:35:42 +0000
Subject: [issue12094] Cannot Launch IDLE
In-Reply-To: <1305587162.23.0.405735006305.issue12094@psf.upfronthosting.co.za>
Message-ID: <1305653742.47.0.48829639155.issue12094@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12094>
_______________________________________

From report at bugs.python.org  Tue May 17 19:41:23 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 17 May 2011 17:41:23 +0000
Subject: [issue12002] ftplib.FTP.abort fails with TypeError on Python 3.x
In-Reply-To: <1304545512.58.0.371208627272.issue12002@psf.upfronthosting.co.za>
Message-ID: <1305654083.94.0.992881400719.issue12002@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12002>
_______________________________________

From report at bugs.python.org  Tue May 17 20:17:20 2011
From: report at bugs.python.org (Jay Parlar)
Date: Tue, 17 May 2011 18:17:20 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1305656240.02.0.23832057026.issue12077@psf.upfronthosting.co.za>


Jay Parlar <parlar at gmail.com> added the comment:

While working on this, I believe it would also make sense to remove all instances of the terms "new-style" and "old-style" from the Descriptor HowTo (and wherever else they might be present)

It still makes sense for them to be present in the 2.7 documentation, but they're concepts that don't exist in 3.x

----------
nosy: +Jay.Parlar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Tue May 17 21:12:07 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 17 May 2011 19:12:07 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

On Windows, if Python is unable to find its .dll it crashes badly. This affects `vurtualenv` project that doesn't copy .dll file. It would be more user friendly if python.exe launcher could detect this situation and fail gracefully.

Such kind of dynamic linking can also serve as an example for building launchers for applications that optionally provide Python scripting depending on if Python .dll is present on the system.

And the ultimate launcher will allow to load any available .dll  This can be extremely handy for apps with embedded Python that use scripts compatible with Python 2.5+

----------
messages: 136173
nosy: techtonik
priority: normal
severity: normal
status: open
title: python.exe crashes if it is unable to find its .dll
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Tue May 17 21:50:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 May 2011 19:50:42 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305661842.62.0.896965305791.issue1746656@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry to reopen, but do these methods really have to return *byte strings* for interface names?
In Python 3, we usually take the position that textually meaningful data should be str, not bytes (even filenames under POSIX). The usual way to do this is to use the "filesystem encoding" (os.fsdecode in pure Python, PyUnicode_DecodeFSDefault in C).

Also, the tests are really minimal. They should at least check the type and structure of values returned by these functions.

----------
nosy: +pitrou
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Tue May 17 22:17:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 17 May 2011 20:17:25 +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: <20110517201706.GA2840@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I've dropped wet-her!
I hope now you're satisfied!!!!!
So the buffer cache is all which remains hot.
How deserted!

> And you could also add a test (I guess that just calling fsync
> with full_sync=True on a valid FD would be enough.

I was able to add two tests as an extension to what is yet tested
about os.fsync(), but that uses an invalid fd.
(At least it enters the conditional and fails as expected.)

> I'm not sure static is necessary, I'd rather make it const.

Yes..

> This code is correct as it is, see other extension modules in
> the stdlib for other examples of this pattern

..but i've used copy+paste here.

> And you could also add a test (I guess that just calling fsync
> with full_sync=True on a valid FD would be enough.

> The alternative would be that full_sync

Ok, i've renamed full_fsync to full_sync.

----------
Added file: http://bugs.python.org/file22016/11877.9.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
@@ -798,7 +798,7 @@
    Availability: Unix.
 
 
-.. function:: fsync(fd)
+.. function:: fsync(fd, full_sync=False)
 
    Force write of file with filedescriptor *fd* to disk.  On Unix, this calls the
    native :c:func:`fsync` function; on Windows, the MS :c:func:`_commit` function.
@@ -807,6 +807,15 @@
    ``f.flush()``, and then do ``os.fsync(f.fileno())``, to ensure that all internal
    buffers associated with *f* are written to disk.
 
+   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.  The optional *full_sync*
+   argument can be used to enforce usage of these special functions if that is
+   appropriate for the *fd* in question.
+
    Availability: Unix, and Windows.
 
 
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
@@ -837,10 +837,10 @@
     singles = ["fchdir", "dup", "fdopen", "fdatasync", "fstat",
                "fstatvfs", "fsync", "tcgetpgrp", "ttyname"]
     #singles.append("close")
-    #We omit close because it doesn'r raise an exception on some platforms
+    # We omit close because it doesn't raise an exception on some platforms
     def get_single(f):
         def helper(self):
-            if  hasattr(os, f):
+            if hasattr(os, f):
                 self.check(getattr(os, f))
         return helper
     for f in singles:
@@ -855,6 +855,11 @@
             self.fail("%r didn't raise a OSError with a bad file descriptor"
                       % f)
 
+    def test_fsync_arg(self):
+        if hasattr(os, "fsync"):
+            self.check(os.fsync, True)
+            self.check(os.fsync, False)
+
     def test_isatty(self):
         if hasattr(os, "isatty"):
             self.assertEqual(os.isatty(support.make_bad_fd()), False)
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -2121,13 +2121,50 @@
 
 #ifdef HAVE_FSYNC
 PyDoc_STRVAR(posix_fsync__doc__,
-"fsync(fildes)\n\n\
-force write of file with filedescriptor to disk.");
-
-static PyObject *
-posix_fsync(PyObject *self, PyObject *fdobj)
-{
-    return posix_fildes(fdobj, fsync);
+"fsync(fildes, full_sync=False)\n\n"
+"force write of file buffers with fildes to disk;\n"
+"full_sync forces flush of disk caches in case fsync() alone is not enough.");
+
+static PyObject *
+posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs)
+{
+    PyObject *fdobj;
+    int full_sync = 0;
+    static char *keywords[] = {"fd", "full_sync", NULL };
+
+    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O|i", keywords,
+                                     &fdobj, &full_sync))
+        return NULL;
+
+    /* See issue 11877 discussion */
+# if ((defined __APPLE__ && defined F_FULLFSYNC) || \
+      (defined __NetBSD__ && defined FDISKSYNC))
+    if (full_sync != 0) {
+        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 */
+        res = fcntl(fd, F_FULLFSYNC);
+        if (res < 0 && errno == ENOTTY)
+            res = fsync(fd);
+#  elif defined __NetBSD__
+        res = fsync_range(fd, FFILESYNC|FDISKSYNC, 0, 0);
+#  endif
+        Py_END_ALLOW_THREADS
+
+        if (res < 0)
+            return posix_error();
+        Py_INCREF(Py_None);
+        return Py_None;
+    } else
+# endif
+        return posix_fildes(fdobj, fsync);
 }
 #endif /* HAVE_FSYNC */
 
@@ -9472,7 +9509,8 @@
     {"fchdir",          posix_fchdir, METH_O, posix_fchdir__doc__},
 #endif
 #ifdef HAVE_FSYNC
-    {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+    {"fsync",           (PyCFunction)posix_fsync, METH_VARARGS|METH_KEYWORDS,
+                        posix_fsync__doc__},
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

From report at bugs.python.org  Tue May 17 22:19:08 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 17 May 2011 20:19:08 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305663548.75.0.550521838847.issue12097@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Which dll was missing in your case? python27.dll, python32.dll or another one?
Virtualenv usually work on Windows. What did it fail to copy?

There is already PEP387 about a "Python launcher" on Windows. Can you please read the specifications, and tell us if they would fit your needs?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Tue May 17 22:22:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 17 May 2011 20:22:25 +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: <1305663745.26.0.073431187798.issue11877@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file21986/11877.8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue May 17 22:33:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 May 2011 20:33:17 +0000
Subject: [issue11877] Change os.fsync() to support physical backing store syncs
In-Reply-To: <20110517201706.GA2840@sherwood.local>
Message-ID: <1305664394.3852.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I've dropped wet-her!
> I hope now you're satisfied!!!!!
> So the buffer cache is all which remains hot.
> How deserted!

I'm not sure I'm always understanding your messages well (I'm not a
native English speaker), but I don't think this kind of joke is
appropriate for the bug tracker.
Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue May 17 22:38:53 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Tue, 17 May 2011 20:38:53 +0000
Subject: [issue12098] Child process running as debug
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>


New submission from Sergey Mezentsev <thebits at yandex.ru>:

I run this code:
"""
from multiprocessing import Pool

def myfunc(x):
    assert False
    #if __debug__: print 'debug'
    return x - 1

if __name__ == '__main__':
    pool = Pool(processes=1)
    it = pool.imap(myfunc, xrange(5)) # or imap_unordered, map
    print it.next()

python -O myscript.py
"""

The myfunc() always raise AssertionError. But I run script with "-O" (optimization) command.

Interpreter is:
"""
Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] on win32
"""

Thanks!

----------
components: Interpreter Core, Library (Lib), Windows
messages: 136178
nosy: thebits
priority: normal
severity: normal
status: open
title: Child process running as debug
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Tue May 17 22:52:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 20:52:48 +0000
Subject: [issue12098] Child process running as debug
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305665568.88.0.847086568916.issue12098@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm unable to reproduce this bug on Linux.

$ cat script.py
from multiprocessing import Pool
import os

def myfunc(x):
    import sys
    print("child", os.getpid(), "optimize?", sys.flags.optimize)
    assert False, "assert False"
    return x

if __name__ == '__main__':
    import sys
    print("parent optimize?", sys.flags.optimize)
    pool = Pool(processes=2)
    pool.map(myfunc, xrange(2)) # or imap_unordered, map

$ python -O script.py
('parent optimize?', 1)
('child', 30397, 'optimize?', 1)
('child', 30398, 'optimize?', 1)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Tue May 17 22:59:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 20:59:39 +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: <1305665979.92.0.751152957288.issue11877@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't like the API because it gives a different behaviour depending on the OS and I don't see how to check that the function does really a full sync.

I would prefer a new option os.fullsync() function which is like your os.fsync(fd, full_sync=False), except that the function doesn't exist if the OS doesn't implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Tue May 17 23:02:49 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Tue, 17 May 2011 21:02:49 +0000
Subject: [issue12098] Child process running as debug
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305666169.95.0.0830778593795.issue12098@psf.upfronthosting.co.za>


Sergey Mezentsev <thebits at yandex.ru> added the comment:

In my system (Windows 7 (64) SP1, Python 2.6.6 32-bit) I have:
"""
d:\temp>python -O pool.py
('parent optimize?', 1)
('child', 4712, 'optimize?', 0)
(Traceback (most recent call last):
'  File "new.py", line 14, in <module>
chil    dpool.map(myfunc, xrange(2)) # or imap_unordered, map'
,   File "C:\Python26\lib\multiprocessing\pool.py", line 148, in map
4712, 'optimize    ?return self.map_async(func, iterable, chunksize).get()
'  File "C:\Python26\lib\multiprocessing\pool.py", line 422, in get
, 0)
    raise self._value
AssertionError: assert False
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Tue May 17 23:13:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 17 May 2011 21:13:35 +0000
Subject: [issue12098] Child process running as debug
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305666815.86.0.286638262759.issue12098@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Under Linux, child processes are created with fork(), so they're run with the exact same environment as the parent process (among which sys.flags.optimize).
I don't know Windows at all, but since I've heard it doesn't have fork(), my guess is that the command-line is constructed before creating the child process, and maybe the -O command line argument is lost.
Just a guess.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Tue May 17 23:14:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 21:14:28 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305666868.63.0.836917878025.issue12098@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Child process running as debug -> Child process running as debug on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Tue May 17 23:15:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 May 2011 21:15:04 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305666904.87.0.565303447855.issue12098@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Tue May 17 23:23:48 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 17 May 2011 21:23:48 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1305667428.05.0.739774828841.issue9811@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

`strftime` does not, indeed, seem to define what behaviour it is supposed to do when given non-supported format characters. Under Windows, in fact, it will crash the runtime (see: issue #10762).

----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Tue May 17 23:36:58 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 17 May 2011 21:36:58 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305668218.55.0.407654153709.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Digging deeper with the Visual Studio debugger, I discovered the following interesting outcome (run with cmd.exe):

    @echo off
    mklink /d sample sample-target
    mkdir sample-target
    echo "" > sample-target\__init__.py
    :: Before KB2467174, returns 0; after, returns -1
    python -c "import ctypes; buf = (ctypes.c_char*256)(); print(ctypes.windll.msvcr90._wstat64i32(u'sample', ctypes.byref(buf)))"
    :: Always returns 13
    python -c "import ctypes; fd = ctypes.c_int(-1); print(ctypes.windll.msvcrt._wsopen_s(ctypes.byref(fd), u'sample', 0, 0x40, 0))"
    rmdir sample
    rmdir /s /q sample-target

The call to _wstat64i32 is returning -1 with the patched CRT... but when I traced _wstat64i32 (on a machine with the patched CRT), it called _wsopen_s, which apparently always returns -1.

So my guess is that the patched CRT changed something about _wstat64i32 such that it doesn't defer to _wsopen_s. I'm going to see if I can get an early version of Visual Studio that I can trace where _wstat64i32 doesn't fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Tue May 17 23:43:03 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 17 May 2011 21:43:03 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305668583.1.0.7302891742.issue12098@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This happens only on Windows, where multiprocessing has to spawn a new intepreter; the -O parameter is certainly omitted.
Unix platforms fork() the current interpreter with all its state and don't have this issue.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Wed May 18 00:03:49 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 17 May 2011 22:03:49 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305669829.64.0.806957861273.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Indeed, this appears to be a bug in stat64.c, specifically a regression in KB2467174. If I look at the code for _wstat64i32, it doesn't have the code that calls into _wsopen_s for symlinked files/dirs, so uses the legacy behavior to stat the target. I suspect it's also a memory leak, because it doesn't properly close the "findhandle" in this case.

Any suggestions on how to handle upstream bugs in Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Wed May 18 00:20:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 22:20:49 +0000
Subject: [issue12096] test_threading.test_waitfor() timeout (1 hour) on x86
	Gentoo 3.x buildbot
In-Reply-To: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>
Message-ID: <E1QMSdE-0003bD-4Q@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a6b4a00fb1c7 by Victor Stinner in branch '3.2':
Issue #12096: Fix a race condition in test_threading.test_waitfor(). Patch
http://hg.python.org/cpython/rev/a6b4a00fb1c7

New changeset c52807b17e03 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12096: Fix a race condition in
http://hg.python.org/cpython/rev/c52807b17e03

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12096>
_______________________________________

From report at bugs.python.org  Wed May 18 00:21:23 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 17 May 2011 22:21:23 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305670883.56.0.619518913481.issue6727@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Wow, nice analysis. http://connect.microsoft.com/ is the external Microsoft bug tracker, as far as I know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Wed May 18 00:22:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 22:22:19 +0000
Subject: [issue12096] test_threading.test_waitfor() timeout (1 hour) on x86
	Gentoo 3.x buildbot
In-Reply-To: <1305645775.56.0.0637230445688.issue12096@psf.upfronthosting.co.za>
Message-ID: <1305670939.43.0.343621912326.issue12096@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, it is a real bug in the test. Bug fixed by your patch. Thanks, I commited your patch.

I don't wait for the buildbot because it's a sporadic (and rare) failure.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12096>
_______________________________________

From report at bugs.python.org  Wed May 18 00:25:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 22:25:59 +0000
Subject: [issue11779] test_mmap.test_large_offset() timeout (1 hour) on "AMD64
	Snow Leopard 3.x" buildbot
In-Reply-To: <1302076762.26.0.815715887004.issue11779@psf.upfronthosting.co.za>
Message-ID: <1305671159.5.0.388035346665.issue11779@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I did not see new failure recently, let's close this issue. Reopen if it is not fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11779>
_______________________________________

From report at bugs.python.org  Wed May 18 00:28:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 May 2011 22:28:30 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1305671310.65.0.949709925871.issue11610@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/issue11610>
_______________________________________

From report at bugs.python.org  Wed May 18 00:30:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 17 May 2011 22:30:26 +0000
Subject: [issue6059] ctypes/uuid-related segmentation fault
In-Reply-To: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>
Message-ID: <1305671426.78.0.225194956402.issue6059@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

neologix, that is right. Importing uuid before importing the other modules does not result in Seg Fault. Till the libc fix is available in Operating systems and as a result in CPython, this is probably the only way to go for.

----------
nosy: +orsenthil -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6059>
_______________________________________

From report at bugs.python.org  Wed May 18 00:40:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 22:40:42 +0000
Subject: [issue6059] ctypes/uuid-related segmentation fault
In-Reply-To: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>
Message-ID: <1305672042.55.0.527012226104.issue6059@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It's probably a libc bug

The bug looks to be specific to the GNU libc. It exists in glibc-2.11.3 and glibc-2.12.2. I suppose that all versions of the GNU libc are affected. The bug has been fixed:
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d26dfc60edc8

I don't know which versions will include the fix.

I don't think that Python can workaround the bug, and so the issue should be fixed.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6059>
_______________________________________

From report at bugs.python.org  Wed May 18 01:07:07 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 17 May 2011 23:07:07 +0000
Subject: [issue12099] re pattern objects have no __class__
In-Reply-To: <1305673627.82.0.93003705972.issue12099@psf.upfronthosting.co.za>
Message-ID: <1305673627.82.0.93003705972.issue12099@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

>>> import re
>>> re.compile('foo')
<_sre.SRE_Pattern object at 0x1043230>
>>> p = re.compile('foo')
>>> p.__class__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __class__

Already fixed in 3.2.

----------
messages: 136193
nosy: michael.foord
priority: normal
severity: normal
stage: test needed
status: open
title: re pattern objects have no __class__
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12099>
_______________________________________

From report at bugs.python.org  Wed May 18 01:10:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 23:10:05 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec at
	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Stateful CJK codecs reset the codec at each call to encode() producing a valid but overlong output:

>>> import codecs
>>> encoder = codecs.getincrementalencoder('hz')()
>>> encoder.encode('\u804a') + encoder.encode('\u804a')
b'~{AD~}~{AD~}'
>>> '\u804a\u804a'.encode('hz')
b'~{ADAD~}'

Multibyte encodings: HZ and all encodings of the ISO 2022 family (e.g. iso-2022-jp).

Attached patch fixes this issue. I don't like how I added the tests, these tests may be moved somewhere else, but HZ codec doesn't have tests today (I opened issue #12057 for that), and ISO 2022 codecs don't have specific tests (test_multibytecodec is "Unit test for multibytecodec itself"). We should maybe also add tests specific to ISO 2022 first?

I hesitate to reset the codec on .encode(text, final=True), but UTF-8-SIG or UTF-16 don't reset the codec if final=True. io.TextIOWrapper only calls encoder.reset() on file.seek(0). On a seek to another position, it calls encoder.setstate(0).

See also issues #12016 and #12057.

----------
components: Interpreter Core
files: cjk_no_reset.patch
keywords: patch
messages: 136194
nosy: haypo, hyeshik.chang, lemburg
priority: normal
severity: normal
status: open
title: Incremental encoders of CJK codecs reset the codec at each call to encode()
versions: Python 3.3
Added file: http://bugs.python.org/file22017/cjk_no_reset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Wed May 18 01:12:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 23:12:41 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305673961.21.0.415899192785.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ISO 2022 encodings don't have tests neither: test_multibytecodec doesn't test directly these encodings but it is "Unit test for multibytecodec itself". We may also add tests specific to ISO 2022 encodings:

 - iso2022_kr
 - iso2022_jp
 - iso2022_jp_1
 - iso2022_jp_2
 - iso2022_jp_2004
 - iso2022_jp_3
 - iso2022_jp_ext

While trying to write tests for the HZ encoding, I found a bug in CJK multibyte encodings => #12100, "Incremental encoders of CJK codecs reset the codec at each call to encode()".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 18 01:30:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2011 23:30:19 +0000
Subject: [issue12099] re pattern objects have no __class__
In-Reply-To: <1305673627.82.0.93003705972.issue12099@psf.upfronthosting.co.za>
Message-ID: <E1QMTiO-0001LD-VX@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c9df95b57af3 by Benjamin Peterson in branch '2.7':
stop using the old brain-dead interface for providing attributes/methods
http://hg.python.org/cpython/rev/c9df95b57af3

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12099>
_______________________________________

From report at bugs.python.org  Wed May 18 01:56:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 23:56:45 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1305676605.78.0.639804793971.issue8796@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 3.2 has been published. Can we start deprecating StreamWriter and StreamReader in Python 3.3 (to remove them from Python 3.4)? The doc should explain how to convert code using codecs into code using the io module (it should be simple), and using a StreamReader/StreamWriter should emit a warning.

--

codecs.StreamWriter writes twice the BOM of UTF-8-SIG, UTF-16, UTF-32 encodings if the file is opened in append mode or after a seek(0). Bug fixed in io.TextIOWrapper (issue #5006). io.TextIOWrapper calls also encoder.setstate(0) on a seek different than seek(0), whereas codecs.StreamWriter doesn't (it is not an incremental encoder, it doesn't have the setstate method).

codecs.StreamReader doesn't ignore the BOM of UTF-8-SIG, UTF-16 or UTF-32 encodings after seek(0). Bug fixed in io.TextIOWrapper (issue #4862).

These bugs should maybe be mentioned in the codecs doc, with a pointer to the io module saying that the io module handles these encodings correctly.

----------
resolution: postponed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Wed May 18 01:56:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2011 23:56:51 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1305676611.48.0.789702668612.issue8796@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: closed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Wed May 18 02:00:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 00:00:29 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1305676829.43.0.569879106061.issue8796@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ... once most Linux distributions have moved to Python 2.6

Debian uses Python 2.6 by default since it's last stable release (Squeeze). I think that it was the last distro using Python 2.5 by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Wed May 18 04:11:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 May 2011 02:11:38 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1305684698.01.0.928279654375.issue8796@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Wed May 18 04:40:02 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 18 May 2011 02:40:02 +0000
Subject: [issue11702] dir on return value of msilib.OpenDatabase() crashes
	python
In-Reply-To: <1301325222.81.0.910767875041.issue11702@psf.upfronthosting.co.za>
Message-ID: <1305686402.76.0.522045077204.issue11702@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

If we can generate a testable MSI file that would be the best. Including a very small pre-generated MSI for the purposes of the test would be acceptable.

As-is, the tests don't pass because my machine has C:\Windows\installer\1032f.msi that gets used for the test, which apparently doesn't work with this functionality, and other machines may end up with the same situation. I'm not sure if that's a bug in the code or in whatever MSI that is, though. The OpenDatabase call returns "unknown error 6e" for both new tests.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11702>
_______________________________________

From report at bugs.python.org  Wed May 18 05:58:35 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 18 May 2011 03:58:35 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305691115.62.0.705372562252.issue12097@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

pythonXX.dll is missing. Virtualenv copies python.exe, which is only 25kB long. It works only if pythonXX.dll is present in system PATH - either installed into Windows\System32 or comes with Mercurial, Bazaar or other frozen app install.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Wed May 18 06:18:54 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 18 May 2011 04:18:54 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305692334.25.0.943327047712.issue12097@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

As for PEPs I think you've meant PEP 397 http://www.python.org/dev/peps/pep-0397/ which is tl; dr for the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Wed May 18 07:12:17 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 18 May 2011 05:12:17 +0000
Subject: [issue12101] PEPs should have consecutive revision numbers
In-Reply-To: <1305695537.09.0.834655351659.issue12101@psf.upfronthosting.co.za>
Message-ID: <1305695537.09.0.834655351659.issue12101@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Currently, PEPs have only hash number, which doesn't explain about how many changes were done to the PEP since my last review. It will be convenient to have consecutive revision number for PEP edits and link it to short history log (like wiki history) with current revision highlighted. This is useful to track when PEP on site is not updated to current version.

----------
components: Devguide
messages: 136204
nosy: techtonik
priority: normal
severity: normal
status: open
title: PEPs should have consecutive revision numbers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12101>
_______________________________________

From report at bugs.python.org  Wed May 18 07:48:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 May 2011 05:48:21 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305697701.71.0.235296556523.issue12097@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Virtualenv only works with an installed Python. This is really a virtualenv limitation, then; your issue looks similar to this one:
https://github.com/pypa/virtualenv/issues/87

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Wed May 18 09:39:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 May 2011 07:39:25 +0000
Subject: [issue12101] PEPs should have consecutive revision numbers
In-Reply-To: <1305695537.09.0.834655351659.issue12101@psf.upfronthosting.co.za>
Message-ID: <1305704365.5.0.650938439607.issue12101@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The Last-Modified date should tell you just the same, without any arbitrary version numbers that don't have a meaning in hg.

And behold, the Last-Modified date already links to the hg page for this PEP, from where you can select the "file log" to get to the list of changes.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12101>
_______________________________________

From report at bugs.python.org  Wed May 18 09:47:13 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 18 May 2011 07:47:13 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305704833.12.0.505778193634.issue12097@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Reopening as I believe the issue is hijacked. Virtualenv is just an example and the fix is discussed on its mailing list.

This issue is about that Python interpreter is not self-contained, not portable, i.e. split into python.exe and pythonXX.dll The only reason for this split is to allow other programs use dynamic linking to load interpreter from .dll Such programs even though they are using pythonXX.dll from different .exe file do not crash. python.exe should not crash also. Moreover - as an open source project - it should serve as an example of proper linking to Python.

It is not covered by PEP 397, because PEP is about launcher that chooses among multiple Python versions and this request about command line launcher for specific Python interpreter. But PEP 397 still can benefit from the research on this feature request - like explaining linking mechanism for developers.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Wed May 18 09:53:22 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 18 May 2011 07:53:22 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1305667428.05.0.739774828841.issue9811@psf.upfronthosting.co.za>
Message-ID: <4DD37AEE.5000409@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Santoso Wijaya wrote:
> 
> Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:
> 
> `strftime` does not, indeed, seem to define what behaviour it is supposed to do when given non-supported format characters. Under Windows, in fact, it will crash the runtime (see: issue #10762).

According to POSIX, it is defined to be undefined:

"""
       If a conversion specification does not correspond to any of  the  above,  the
       behavior is undefined.
"""

Of course, crashing the runtime is not a good way to interpret this ;-)

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Wed May 18 09:55:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 May 2011 07:55:53 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305705353.02.0.0910168894246.issue12084@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Brian, do you think you'll be able to finish this for 3.2.1?

If we do fix it, we'd need a second rc (not a problem for me).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Wed May 18 10:01:18 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 May 2011 08:01:18 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305705678.03.0.924615501951.issue12097@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You are right, the use case is broader than virtualenv.

> The only reason for this split is to allow other programs use dynamic linking
For me the main reason is to support extension modules. On Windows, a DLL (or a .pyd) cannot resolve symbols in the main .exe program.

Do you have more specifications about such a launcher? How would it find the .dll?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Wed May 18 10:22:16 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 18 May 2011 08:22:16 +0000
Subject: [issue9811] strftime strips '%' from unknown format codes on OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1305706936.89.0.714627403597.issue9811@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

Yeah, I meant undefined. I looked that up when writing a patch for issue #10762.

Correction: It *used to* crash on Windows, before the patch was applied.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9811>
_______________________________________

From report at bugs.python.org  Wed May 18 10:25:55 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 18 May 2011 08:25:55 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1305676605.78.0.639804793971.issue8796@psf.upfronthosting.co.za>
Message-ID: <4DD3828F.2060106@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Python 3.2 has been published. Can we start deprecating StreamWriter and StreamReader in Python 3.3 (to remove them from Python 3.4)? The doc should explain how to convert code using codecs into code using the io module (it should be simple), and using a StreamReader/StreamWriter should emit a warning.

This ticket is about deprecating codecs.open(), not about
StreamWriter and StreamReader.

The arguments mentioned here against doing that anytime soon
still stand.

I'm -1 on deprecating StreamWriter and StreamReader as they provide
different mechanisms than the io layer which has a specific focus
on files and buffers.

> --
> 
> codecs.StreamWriter writes twice the BOM of UTF-8-SIG, UTF-16, UTF-32 encodings if the file is opened in append mode or after a seek(0). Bug fixed in io.TextIOWrapper (issue #5006). io.TextIOWrapper calls also encoder.setstate(0) on a seek different than seek(0), whereas codecs.StreamWriter doesn't (it is not an incremental encoder, it doesn't have the setstate method).
> 
> codecs.StreamReader doesn't ignore the BOM of UTF-8-SIG, UTF-16 or UTF-32 encodings after seek(0). Bug fixed in io.TextIOWrapper (issue #4862).
> 
> These bugs should maybe be mentioned in the codecs doc, with a pointer to the io module saying that the io module handles these encodings correctly.

Those are not bugs of the generic codecs.StreamWriter/StreamReader
implementations or their concept. They are bugs in those specific
codecs.

The codecs StreamWriter and StreamReader concept was explicitly
designed to be able to have state. However, the generic implementation
does not make use of such state for the purpose of writing special
beginning-of-file markers - that's just way to specific for general
purpose implementations. They do use state to implement buffered
reads.

It would certainly be possible to make the implementations of
the codecs you mentioned smarter to handle writing BOMs correctly,
e.g. by making use of the incremental encoder/decoders, if there's
interest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Wed May 18 10:26:50 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 May 2011 08:26:50 +0000
Subject: [issue12097] python.exe crashes if it is unable to find its .dll
In-Reply-To: <1305659527.57.0.173805273526.issue12097@psf.upfronthosting.co.za>
Message-ID: <1305707210.86.0.54664815065.issue12097@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

And most importantly, what would it do if the .dll is not found?  What can it do, other than present a message box "Cannot find pythonXY.dll, exiting."

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12097>
_______________________________________

From report at bugs.python.org  Wed May 18 11:17:30 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 18 May 2011 09:17: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: <20110518091719.GA21530@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Excusing myself seems to be the only "probates Mittel".
@Antoine Pitrou: It was a real shame to read your mail.
(It's sometimes so loud that "i don't even hear what i write".)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed May 18 11:29:59 2011
From: report at bugs.python.org (lekma)
Date: Wed, 18 May 2011 09:29:59 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1305710999.76.0.424393533081.issue10271@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

Is there anything else I should be doing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Wed May 18 11:44:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 09:44:04 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1305711844.5.0.649556052513.issue8796@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This ticket is about deprecating codecs.open(), not about
> StreamWriter and StreamReader.

Right. I may open a different issue.

Can we start by modifying codecs.open() to use the builtin open() (to reuse TextIOWrapper)?

> I'm -1 on deprecating StreamWriter and StreamReader as they provide
> different mechanisms than the io layer which has a specific focus
> on files and buffers.

What are the usecases of StreamReader and StreamWriter, not covered by TextIOWrapper?

TextIOWrapper are used in Python for:

 - files (e.g. open)
 - processes (e.g. open.popen)
 - emails (e.g. mailbox.Message)
 - sockets (e.g. socket.makefile)
 - and maybe other things

StreamReader and StreamWriter are used for:

 - read/write files in Sphinx 1.0.7 (written for Python 2)
 - write the output in pygment 1.3.1 (written for Python 2)
 - but not in the Python interpreter or standard library

*Quick* search of other usages of StreamReader and StreamWriter on the WWW:

 - twisted/mail/imap4.py
 - feeds2imap implements a 'mod-utf-7' codec, pyflag implements a 'ms-pst' codec, pygsm implements a 'gsm0338' codec, so they have StreamReader and StreamWriter classes (but I don't know if these classes are used)

> It would certainly be possible to make the implementations of
> the codecs you mentioned smarter to handle writing BOMs correctly,
> e.g. by making use of the incremental encoder/decoders, if there's
> interest.

Yes, it is possible to fix StreamReader and StreamWriter classes of the mentionned codecs, but it's not possible to write a generic fix in codecs.py. This is exactly why I dislike StreamReader and StreamWriter: they are not incremental and so don't have reset() or setstate() methods. When you implement a StreamReader or StreamWriter class, you have to reimpelment a pseudo-incremental encoder. Compare for example IncrementalEncoder and StreamWriter classes of UTF-16: most code is duplicated.

Because StreamReader and StreamWriter are not incremental, they are not efficient, and it's difficult to handle some issues like BOM which require to handle the codec state.

TextIOWrapper "simply" reuses incremental encoders and decoders, and so use reset() and setstate() methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Wed May 18 11:56:04 2011
From: report at bugs.python.org (rion)
Date: Wed, 18 May 2011 09:56:04 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>


New submission from rion <rion4ik at gmail.com>:

Not flushed file gives next results:

rion at rionhost ~/temp $ python2 test.py 
Traceback (most recent call last):
  File "test.py", line 10, in <module>
    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
mmap.error: [Errno 22] Invalid argument
rion at rionhost ~/temp $ python3 test.py 
Traceback (most recent call last):
  File "test.py", line 10, in <module>
    m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
ValueError: mmap offset is greater than file size


testcase:

import mmap
from tempfile import TemporaryFile

f = TemporaryFile()
f.write(b"hello world")

#f.flush()

m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)


just uncomment f.flush() and try again. feel the difference.

suggestion: force flush on file descriptor when passed to mmap.

----------
components: None
messages: 136217
nosy: rion4ik at gmail.com
priority: normal
severity: normal
status: open
title: mmap requires file to be synced
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Wed May 18 12:21:18 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 18 May 2011 10:21:18 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305714078.15.0.302576278342.issue12102@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

your suggestion doesn't work. there's no such thing like a "flush on file descriptor".

----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Wed May 18 12:23:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 10:23:08 +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: <1305714188.15.0.969698773274.issue11877@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #12102.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Wed May 18 12:23:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 10:23:21 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305714201.51.0.815366532315.issue12102@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #11877 and #11277.

----------
nosy: +haypo, sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Wed May 18 12:39:43 2011
From: report at bugs.python.org (rion)
Date: Wed, 18 May 2011 10:39:43 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305715183.28.0.277256822187.issue12102@psf.upfronthosting.co.za>


rion <rion4ik at gmail.com> added the comment:

okay guys I'm not going to read all this stuff.
just document it or fix.

thanks for quick reply

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Wed May 18 12:54:13 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Wed, 18 May 2011 10:54:13 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1305716053.35.0.622601056774.issue12009@psf.upfronthosting.co.za>


Ruslan Mstoi <rmstoi at gmail.com> added the comment:

I agree, the test input was becoming unmaintainable. So, I updated the patch with the refactored unit tests.

----------
Added file: http://bugs.python.org/file22018/issue12009_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Wed May 18 13:01:25 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 11:01:25 +0000
Subject: [issue12103] Documentation of open() does not claim 'e' support in
	mode string
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

open() and friends (like temporaryfile) does not document 'e' letter in second arguement. At least on Linux, it opens file with O_CLOEXEC.
Not sure under Windows.

Also, there are other interesting letters (man -a fopen), like:

c (since glibc 2.3.3)
       Do not make the open operation, or  subsequent  read  and  write operations, thread cancellation points.
e (since glibc 2.7)
       Open  the  file  with  the O_CLOEXEC flag.  See open(2) for more information.
m (since glibc 2.3)
       Attempt to access the file using mmap(2), rather than I/O system calls  (read(2),  write(2)).   Currently, use of mmap(2) is only attempted for a file opened for reading.

x      Open the file exclusively (like the O_EXCL flag of open(2)).  If the  file  already exists, fopen() fails, and sets errno to EEXIST.  This flag is ignored for fdopen().

----------
assignee: docs at python
components: Documentation
messages: 136223
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: Documentation of open() does not claim 'e' support in mode string

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12103>
_______________________________________

From report at bugs.python.org  Wed May 18 13:01:37 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 11:01:37 +0000
Subject: [issue12103] Documentation of open() does not claim 'e' support in
	mode string
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1305716497.09.0.087147158729.issue12103@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12103>
_______________________________________

From report at bugs.python.org  Wed May 18 13:04:32 2011
From: report at bugs.python.org (Tor Arvid Lund)
Date: Wed, 18 May 2011 11:04:32 +0000
Subject: [issue4621] zipfile returns string but expects binary
In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za>
Message-ID: <1305716672.87.0.693969147277.issue4621@psf.upfronthosting.co.za>


Tor Arvid Lund <torarvid at gmail.com> added the comment:

I was wondering what has prevented Eddies patch from being included into python. Has nobody volunteered to verify that it works? I would be willing to do that, though I have never compiled python on any platform before.

It just seems a bit silly to me that python cannot work with zip files with unicode file names... I just now had to do 'os.system("unzip.exe ...")' because zipfile did not work for me...

----------
nosy: +talund

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4621>
_______________________________________

From report at bugs.python.org  Wed May 18 13:16:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 11:16:07 +0000
Subject: [issue12103] Documentation of open() does not claim 'e' support in
	mode string
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1305717367.97.0.979677541207.issue12103@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

c, e, m and x flags are specific to the GNU libc. Python 2 does basically pass the mode to fopen() unmodified (there is one exception, the U flag). fopen() of Visual C++ 2005 has other flags:

c
Enable the commit flag for the associated filename so that the contents of the file buffer are written directly to disk if either fflush or _flushall is called.

n
Reset the commit flag for the associated filename to "no-commit." This is the default. It also overrides the global commit flag if you link your program with COMMODE.OBJ. The global commit flag default is "no-commit" unless you explicitly link your program with COMMODE.OBJ (see Link Options).

N
Specifies that the file is not inherited by child processes.

S
Specifies that caching is optimized for, but not restricted to, sequential access from disk.

R
Specifies that caching is optimized for, but not restricted to, random access from disk.

T
Specifies a file as temporary. If possible, it is not flushed to disk.

D
Specifies a file as temporary. It is deleted when the last file pointer is closed.

ccs=ENCODING
Specifies the coded character set to use (UTF-8, UTF-16LE, or UNICODE) for this file. Leave unspecified if you want ANSI encoding. This option is available in Visual C++ 2005 and later.

http://msdn.microsoft.com/en-us/library/yeby3zcb(v=vs.80).aspx

I don't think that non standard modes should be documented in Python doc, but we may add links to specific documentations like the GNU libc and Microsoft fopen().

--

This issue is specific to Python 2, Python 3 doesn't use fopen() anymore.

----------
nosy: +haypo
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12103>
_______________________________________

From report at bugs.python.org  Wed May 18 13:30:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 11:30:58 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305718258.51.0.127522238227.issue12048@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #4621.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Wed May 18 13:31:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 11:31:33 +0000
Subject: [issue4621] zipfile returns string but expects binary
In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za>
Message-ID: <1305718293.12.0.641253052964.issue4621@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue looks to be a duplicate of #10801 which was only fixed (33543b4e0e5d) in Python 3.2. See also #12048: similar issue in Python 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4621>
_______________________________________

From report at bugs.python.org  Wed May 18 13:43:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2011 11:43:29 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <E1QMfA0-0003tj-9j@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1f0f0e317873 by Victor Stinner in branch '3.1':
Backport commit 33543b4e0e5d from Python 3.2: #10801: In zipfile, support
http://hg.python.org/cpython/rev/1f0f0e317873

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Wed May 18 13:44:08 2011
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 18 May 2011 11:44:08 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1305719048.28.0.176129450004.issue10271@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/issue10271>
_______________________________________

From report at bugs.python.org  Wed May 18 13:48:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2011 11:48:43 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <E1QMfF4-0004Qj-LL@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 243c78fbbb49 by Victor Stinner in branch '3.1':
Ooops, add the missing file of the backport of commit 33543b4e0e5d from Python
http://hg.python.org/cpython/rev/243c78fbbb49

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Wed May 18 13:52:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 May 2011 11:52:47 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1305719567.11.0.550231601034.issue10271@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Brett's been very busy with real life.  Maybe someone else can commit this.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Wed May 18 14:00:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 12:00:18 +0000
Subject: [issue4621] zipfile returns string but expects binary
In-Reply-To: <1228926467.09.0.231688302794.issue4621@psf.upfronthosting.co.za>
Message-ID: <1305720018.71.0.742334604662.issue4621@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The initial problem is clearly a duplicate of issue #10801 which is now fixed in Python 3.1+ (I just backported the fix to Python 3.1).

> I just "discovered" that attempting to open zip member "test\file"
> fails where attempting to open "test/file" works. (...)
> It seems pretty clear that zipfile should do that for me, though.

@v+python: I don't think so, but others may agree with you. Please open a new issue, because it is unrelated to the initial bug report.

I'm closing this issue because the initial is now fixed.

For x.zip (UTF-8 encoded filenames with the "Unicode" flag) problem, there is already the issue #10614 which handles this case.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4621>
_______________________________________

From report at bugs.python.org  Wed May 18 14:01:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 12:01:37 +0000
Subject: [issue12048] Python 3, ZipFile Bug In Chinese
In-Reply-To: <1305014397.56.0.923241033175.issue12048@psf.upfronthosting.co.za>
Message-ID: <1305720097.08.0.642963549494.issue12048@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue is just another example of the issue #10614: I'm closing it as a duplicate.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12048>
_______________________________________

From report at bugs.python.org  Wed May 18 14:02:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 12:02:34 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1305720154.69.0.428550793483.issue10614@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I closed issue #12048 as a duplicate of this issue: yaoyu wants to uncompress a ZIP file having filenames encoded to GBK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Wed May 18 14:04:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 May 2011 12:04:32 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305720272.7.0.624774223749.issue12057@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Haypo, since you've created a new directory there are makefile (and PC build file, I think) updates that will need to be made.  (This should be documented in the dev guide if it isn't already.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 18 14:20:52 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Wed, 18 May 2011 12:20:52 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1305721252.06.0.252945166347.issue12009@psf.upfronthosting.co.za>


Changes by Ruslan Mstoi <rmstoi at gmail.com>:


Removed file: http://bugs.python.org/file22018/issue12009_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Wed May 18 14:23:08 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Wed, 18 May 2011 12:23:08 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1305721388.34.0.954104378722.issue12009@psf.upfronthosting.co.za>


Ruslan Mstoi <rmstoi at gmail.com> added the comment:

removed leftover debug code from patch

----------
Added file: http://bugs.python.org/file22019/issue12009_patch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Wed May 18 14:31:01 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 18 May 2011 12:31:01 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305715183.28.0.277256822187.issue12102@psf.upfronthosting.co.za>
Message-ID: <20110518123053.GA21981@nothing>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@ rion wrote (2011-05-18 12:39+0200):
> just document it or fix.

Hello, zion, Victor, i'm proposing a documentation patch.
It applies to 2.7 and 3.3 (from yesterday).

----------
keywords: +patch
Added file: http://bugs.python.org/file22020/12102.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/mmap.rst b/Doc/library/mmap.rst
--- a/Doc/library/mmap.rst
+++ b/Doc/library/mmap.rst
@@ -21,6 +21,11 @@
 :func:`os.open` function, which returns a file descriptor directly (the file
 still needs to be closed when done).
 
+..note::
+   If you want to create a memory-mapping for a writable, buffered file, you
+   should :func:`flush` the file first.  This is necessary to ensure local
+   modifications to the buffers are actually available to the mapping.
+
 For both the Unix and Windows versions of the constructor, *access* may be
 specified as an optional keyword parameter. *access* accepts one of three
 values: :const:`ACCESS_READ`, :const:`ACCESS_WRITE`, or :const:`ACCESS_COPY`

From report at bugs.python.org  Wed May 18 14:33:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 12:33:33 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305722013.83.0.601785510383.issue12102@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Hello, zion, Victor, i'm proposing a documentation patch.

I like it.

I don't think that Python should guess what the user expects (i.e. Python should not sync the file *implicitly*).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Wed May 18 14:39:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 18 May 2011 12:39:28 +0000
Subject: [issue706263] print raises exception when no console available
Message-ID: <1305722368.16.0.203251360388.issue706263@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Does this affects Python 3?

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706263>
_______________________________________

From report at bugs.python.org  Wed May 18 14:39:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2011 12:39:31 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305722371.16.0.693046328315.issue12098@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that the problem is in Popen.get_command_line() of multiprocessing.forking.

There are other options changing Python behaviour: -b, -B, -E, -u, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Wed May 18 14:42:39 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 May 2011 12:42:39 +0000
Subject: [issue706263] print raises exception when no console available
Message-ID: <1305722559.46.0.443842390176.issue706263@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Python 3 is not affected: pythonw.exe sets sys.stderr to None, and print() silently discards the output in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706263>
_______________________________________

From report at bugs.python.org  Wed May 18 14:45:37 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 May 2011 12:45:37 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305722737.46.0.653052852413.issue12098@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Wed May 18 15:03:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 May 2011 13:03:59 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305723839.98.0.873824470564.issue12098@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We already have some logic for that:
http://hg.python.org/cpython/file/default/Lib/test/support.py#l1398

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Wed May 18 15:09:54 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 18 May 2011 13:09:54 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305722013.83.0.601785510383.issue12102@psf.upfronthosting.co.za>
Message-ID: <20110518130948.GB22111@nothing>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

@ STINNER Victor wrote (2011-05-18 14:33+0200):
> I don't think that Python should guess what the user expects
> (i.e. Python should not sync the file *implicitly*).

Before i've found F_FULLFSYNC i indeed have had a solution which
tracked the open() of all files, so that mmap() could check wether
a file had been opened in write mode or not.  ;|
Python does not do that by default (AFAIK).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Wed May 18 15:23:14 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 18 May 2011 13:23:14 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305724994.89.0.388235548882.issue12102@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> I don't think that Python should guess what the user expects (i.e. Python should not sync the file *implicitly*).

Agreed.

The documentation patch looks good.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Wed May 18 15:40:46 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 18 May 2011 13:40:46 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305726046.66.0.0169018804563.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I'm hoping to. I have time to work on it tonight and tomorrow night US/Chicago time and will keep you posted.

----------
assignee:  -> brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Wed May 18 17:24:30 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Wed, 18 May 2011 15:24:30 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305732270.18.0.951474455893.issue12098@psf.upfronthosting.co.za>


Sergey Mezentsev <thebits at yandex.ru> added the comment:

I create patch for Popen.get_command_line() ('2.6' and 'default' branches).

I don't know how to write the test. The sys.flags structure are read only.

----------
keywords: +patch
Added file: http://bugs.python.org/file22021/Issue12098.branch-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Wed May 18 17:24:37 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Wed, 18 May 2011 15:24:37 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305732277.12.0.672899584754.issue12098@psf.upfronthosting.co.za>


Changes by Sergey Mezentsev <thebits at yandex.ru>:


Added file: http://bugs.python.org/file22022/Issue12098.branch-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Wed May 18 17:43:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 May 2011 15:43:47 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1305733427.18.0.262464732319.issue6459@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Packaging (due to merge with 3.3 shortly) uses init, not PyInit.  I?ll fix it.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +alexis, eric.araujo
status: closed -> open
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Wed May 18 17:47:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 May 2011 15:47:40 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1305733660.56.0.858617992283.issue10126@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils2 has been converted to 3.x and will be merged into 3.3 under the name packaging shortly.  The fix has not been ported; I applied the patch for build_ext and its test but didn?t succeed.

----------
status: closed -> open
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Wed May 18 18:04:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2011 16:04:19 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <E1QMjEQ-0004Kb-32@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6737de76487b by Antoine Pitrou in branch 'default':
Issue #8809: The SMTP_SSL constructor and SMTP.starttls() now support
http://hg.python.org/cpython/rev/6737de76487b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed May 18 18:05:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 May 2011 16:05:44 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1305734744.14.0.43683474073.issue8809@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you Kasun. I did a couple of minor style fixes (whitespace at end of line, and spaces around the '=' assignment sign). I also added a test for starttls(), since it turns out gmail.com supports it on port 25.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed May 18 18:17:42 2011
From: report at bugs.python.org (Kasun Herath)
Date: Wed, 18 May 2011 16:17:42 +0000
Subject: [issue8809] smtplib should support SSL contexts
In-Reply-To: <1274717742.76.0.780111419761.issue8809@psf.upfronthosting.co.za>
Message-ID: <1305735462.31.0.72211879689.issue8809@psf.upfronthosting.co.za>


Kasun Herath <kasunh01 at gmail.com> added the comment:

Thanks Antoine

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8809>
_______________________________________

From report at bugs.python.org  Wed May 18 18:27:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 May 2011 16:27:19 +0000
Subject: [issue12065] test_ssl failure when svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <1305736039.06.0.753731580605.issue12065@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22023/ssl_connect_ex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12065>
_______________________________________

From report at bugs.python.org  Wed May 18 18:42:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 May 2011 16:42:02 +0000
Subject: [issue12068] test_logging failure in test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <1305736922.53.0.264367583294.issue12068@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Still happens sometimes:

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/133/steps/test/logs/stdio

----------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 582, in process_request_thread
    self.finish_request(request, client_address)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 641, in __init__
    self.finish()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 713, in finish
    self.socket.sendto(self.wfile.getvalue(), self.client_address)
socket.error: [Errno 9] Bad file descriptor
test test_logging failed -- Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_logging.py", line 2525, in test_listen_config_10_ok
    ], stream=output)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_logging.py", line 162, in assert_log_lines
    '%s vs. %s' % (actual_lines, expected_values))
AssertionError: 4 != 2 : ["Exception happened during processing of request from ('192.168.0.106', 33509)", '----------------------------------------', 'WARNING ++ 1', 'ERROR ++ 4'] vs. [('WARNING', '1'), ('ERROR', '4')]

----------------------------------------
Exception happened during processing of request from ('192.168.0.106', 33512)
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 582, in process_request_thread
    self.finish_request(request, client_address)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 641, in __init__
    self.finish()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 713, in finish
    self.socket.sendto(self.wfile.getvalue(), self.client_address)
socket.error: [Errno 9] Bad file descriptor
----------------------------------------

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12068>
_______________________________________

From report at bugs.python.org  Wed May 18 18:49:06 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 18 May 2011 16:49:06 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305737346.0.0.0854036574618.issue12084@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Brian, I'm available to help with this tomorrow evening; let me know if you want to team up on it then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Wed May 18 18:52:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2011 16:52:35 +0000
Subject: [issue12065] test_ssl failure when svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <E1QMjz7-0000Ym-Ve@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 019d8ccdf03b by Antoine Pitrou in branch '3.2':
Issue #12065: connect_ex() on an SSL socket now returns the original errno
http://hg.python.org/cpython/rev/019d8ccdf03b

New changeset 162ed9841f14 by Antoine Pitrou in branch 'default':
Issue #12065: connect_ex() on an SSL socket now returns the original errno
http://hg.python.org/cpython/rev/162ed9841f14

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12065>
_______________________________________

From report at bugs.python.org  Wed May 18 18:53:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 May 2011 16:53:36 +0000
Subject: [issue12065] test_ssl failure when svn.python.org fails to resolve
In-Reply-To: <1305228793.43.0.352880054112.issue12065@psf.upfronthosting.co.za>
Message-ID: <1305737616.25.0.76277667018.issue12065@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/issue12065>
_______________________________________

From report at bugs.python.org  Wed May 18 18:58:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 18 May 2011 16:58:51 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1305737931.5.0.943560511058.issue12090@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Wed May 18 19:13:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 18 May 2011 17:13:04 +0000
Subject: [issue6059] ctypes/uuid-related segmentation fault
In-Reply-To: <1242699417.24.0.211949858612.issue6059@psf.upfronthosting.co.za>
Message-ID: <1305738784.36.0.780218386828.issue6059@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Importing uuid before importing the other modules does not result in Seg Fault

Alright.
In that case, I'm closing this bug as invalid.

Until distributions start shipping their glibc with this patch, the workaround is simply to import uuid first.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6059>
_______________________________________

From report at bugs.python.org  Wed May 18 19:22:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 May 2011 17:22:34 +0000
Subject: [issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.3"
	but "10.5" during configure
In-Reply-To: <1280955591.23.0.0206270993017.issue9516@psf.upfronthosting.co.za>
Message-ID: <1305739354.02.0.387945467417.issue9516@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Don?t you get ResourceWarnings from the popens and the unclosed file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9516>
_______________________________________

From report at bugs.python.org  Wed May 18 20:47:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 18 May 2011 18:47:43 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1305744463.47.0.012390926299.issue10882@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

test_os fails on the Fedora bot (--without-threads):

test test_os crashed -- Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1037, in runtest_inner
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 437, in load_module
    return self._load_module(fullname)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 141, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 342, in _load_module
    exec(code_object, module.__dict__)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_os.py", line 1312, in <module>
    class SendfileTestServer(asyncore.dispatcher, threading.Thread):
AttributeError: 'NoneType' object has no attribute 'Thread'

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Wed May 18 21:05:26 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 19:05:26 +0000
Subject: [issue12104] os.path.join('/some/path',
	'') adds extra slash at end of result
In-Reply-To: <1305745526.57.0.545420875857.issue12104@psf.upfronthosting.co.za>
Message-ID: <1305745526.57.0.545420875857.issue12104@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

os.path.join('/some/path', '') adds extra slash at end of result. I expect in that case return value should be '/some/path' but not '/some/path/'

----------
components: Library (Lib)
messages: 136258
nosy: mmarkk
priority: normal
severity: normal
status: open
title: os.path.join('/some/path', '') adds extra slash at end of result
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12104>
_______________________________________

From report at bugs.python.org  Wed May 18 21:11:29 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 19:11:29 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

In Python3 I'm not able to use open('xxx', 're') as it does not call fopen() anymore. What about extra flags like 'e'=O_CLOEXEC?

P.S.
see issue12103 for list of needed flags

P.P.S
does 2to3 tool properly detect such cases?

----------
messages: 136259
nosy: mmarkk
priority: normal
severity: normal
status: open
title: open() does not able to set flags, such as O_CLOEXEC
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Wed May 18 21:11:54 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 18 May 2011 19:11:54 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305745914.27.0.596124751261.issue12105@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Wed May 18 21:28:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2011 19:28:46 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <E1QMmQH-0006Vn-6W@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c45e92bd4d81 by Giampaolo Rodola' in branch 'default':
os.sendfile() test: fix "AttributeError: 'NoneType' object has no attribute 'Thread'" when running tests with --without-threads option.
http://hg.python.org/cpython/rev/c45e92bd4d81

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Wed May 18 22:57:09 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 May 2011 20:57:09 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305752229.55.0.31795865883.issue12105@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

These "needed" flags are actually nonstandard extensions of the libc fopen() function on some platforms.

In python3, one can still use fcntl(f.fileno(), FD_SET, FD_CLOEXEC), but a "flags" parameter would be more convenient.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Wed May 18 23:45:20 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 18 May 2011 21:45:20 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

This patch causes multiple with statements with multiple with items to be represented in the AST instead of flattened as currently happens.

----------
components: Interpreter Core
files: fixwith.patch
keywords: patch
messages: 136262
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: reflect syntatic sugar in with ast
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22024/fixwith.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Wed May 18 23:51:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 18 May 2011 21:51:32 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305755492.12.0.726045974876.issue1746656@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch:
- those functions now accept and return str, not bytes arrays
- some of them were not declared static, it's now fixed
- use PyErr_SetFromErrno when errno is set
- add tests (return type, nonexistent interface name/index and invalid argument)
- cleanup

Note that I'm not sure about my char * <-> PyObject conversions, encoding/unicode issues are really something I'm completely oblivious to.

----------
nosy: +neologix
Added file: http://bugs.python.org/file22025/socket_if.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Wed May 18 23:53:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 18 May 2011 21:53:14 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305755594.5.0.454081079002.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> In python3, one can still use fcntl(f.fileno(), FD_SET, FD_CLOEXEC)

Note that it's not atomic.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Thu May 19 01:13:07 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 18 May 2011 23:13:07 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305760387.48.0.46140060611.issue1746656@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/issue1746656>
_______________________________________

From report at bugs.python.org  Thu May 19 02:34:37 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Thu, 19 May 2011 00:34:37 +0000
Subject: [issue6474] Inconsistent TypeError message on function calls with
	wrong number of arguments
In-Reply-To: <1247495805.32.0.528519491274.issue6474@psf.upfronthosting.co.za>
Message-ID: <1305765277.74.0.134592344913.issue6474@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

$ python3.2
Python 3.2 (r32:88445, Mar 28 2011, 16:46:36) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.core import Extension
>>> Extension('myext', define_macros=[])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() takes at least 3 arguments (3 given)
>>> 
$ python3.1
Python 3.1.3 (r313:86834, Mar 28 2011, 16:44:43) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.core import Extension
>>> Extension('myext', define_macros=[])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() takes at least 3 non-keyword positional arguments (2 given)
>>> 

Looking at the patch committed in r79235, it changes the message to display the total number of arguments passed in and not just required ones. This specific change should be reversed since it produces messages like the one quoted above. (In case you were wondering, passing another optional keyword argument does indeed result in a complaint that at least 3 arguments are taken but 4 are passed.) For even better results, I would suggest rewording the message to make it clear that the requirement refers only to arguments without default values.

----------
nosy: +chortos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6474>
_______________________________________

From report at bugs.python.org  Thu May 19 05:00:02 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 19 May 2011 03:00:02 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1305774002.23.0.388964958797.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

With the patch applied, the new test fails along with test.test_os.WalkTests.test_traversal and test.test_os.Win32SymlinkTests.test_directory_link.

Overall, I agree that this doesn't work correctly. The patch, which is pretty large, breaks more than it fixes.

I'll see if I can make time during the day tomorrow to look further into the code, and I'll try to coordinate with Jason if possible.


(for anyone else looking at this, remember to run your command prompt as administrator)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Thu May 19 06:02:39 2011
From: report at bugs.python.org (Tom McDermott)
Date: Thu, 19 May 2011 04:02:39 +0000
Subject: [issue11643] Use |version| instead of X.Y in the doc
In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za>
Message-ID: <1305777759.02.0.771466394321.issue11643@psf.upfronthosting.co.za>


Tom McDermott <sponster at gmail.com> added the comment:

Things are slightly worse than this issue suggests: the Sphinx formatting string |version| has leaked into the html docs in a few places (library/site.html for example).

The difficulty is that Sphinx isn't expanding the |version| variable inside :file: markup.

----------
nosy: +sponster

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11643>
_______________________________________

From report at bugs.python.org  Thu May 19 07:53:26 2011
From: report at bugs.python.org (Alexey Smirnov)
Date: Thu, 19 May 2011 05:53:26 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305784406.92.0.0288135970843.issue12105@psf.upfronthosting.co.za>


Changes by Alexey Smirnov <alexey.smirnov at gmx.com>:


----------
nosy: +alexey-smirnov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Thu May 19 09:45:59 2011
From: report at bugs.python.org (Ameya Lokare)
Date: Thu, 19 May 2011 07:45:59 +0000
Subject: [issue7969] shutil.copytree error handling non-standard and partially
	broken
In-Reply-To: <1266617058.24.0.24785922897.issue7969@psf.upfronthosting.co.za>
Message-ID: <1305791159.99.0.182179818473.issue7969@psf.upfronthosting.co.za>


Ameya Lokare <lokare.ameya at gmail.com> added the comment:

I've attached a proposed doc patch. I figured I'd move the Error argument format in the description of shutil.copytree, since the format is different for other functions (shutil.move, for example).

----------
keywords: +patch
nosy: +lokare.ameya
Added file: http://bugs.python.org/file22026/shutil_copytree_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7969>
_______________________________________

From report at bugs.python.org  Thu May 19 10:25:09 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Thu, 19 May 2011 08:25:09 +0000
Subject: [issue4934] tp_del and tp_version_tag undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1305793509.2.0.0440023456545.issue4934@psf.upfronthosting.co.za>


Changes by Martin von Gagern <Martin.vGagern at gmx.net>:


----------
nosy: +gagern

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4934>
_______________________________________

From report at bugs.python.org  Thu May 19 11:13:57 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 19 May 2011 09:13:57 +0000
Subject: [issue12068] test_logging failure in test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <1305796437.02.0.200457326416.issue12068@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's not the same error, but there's no point opening another issue for it. The earlier error occurred more frequently, and was specifically due to some changes I made, whereas this error hasn't occurred before and appears to be due to some sort of network glitch. On the same buildbot, later revisions have run without errors, with no changes to test_logging:

162ed9841f147f37d2077a1848eb9aff130b71fb
05836e84e584d3c529e74fba4b99da95df17ef24
c45e92bd4d81713603b7271cc7f61b7457296563

I'll mark as pending and keep an eye on it, but if the failure doesn't recur in the next week or so I'll close the issue again.

----------
resolution: fixed -> 
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12068>
_______________________________________

From report at bugs.python.org  Thu May 19 11:15:26 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 19 May 2011 09:15:26 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1305796526.85.0.352577571587.issue11969@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Test attached.

----------
Added file: http://bugs.python.org/file22027/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Thu May 19 11:46:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 09:46:53 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305798413.89.0.227171793879.issue1746656@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here's a patch:
> - those functions now accept and return str, not bytes arrays

You use UTF-8 encoding:

+                "Is", ni[i].if_index, ni[i].if_name);
+    if (!PyArg_ParseTuple(args, "s:if_nametoindex", &ifname))

You should also use the FS encoding with surrogateescape error handler:

 - parse arguments using "O&" format with PyUnicode_FSConverter: it gives you a PyBytes object, then use PyBytes_AS_STRING() and PyBytes_GET_SIZE()
 - use PyUnicode_DecodeFSDefault() to decode a byte string

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Thu May 19 11:49:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 09:49:56 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305798596.36.0.189836046097.issue1746656@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Example with a non-ASCII interface name:

$ sudo tunctl -u haypo -t unicode?
Set 'unicode?' persistent and owned by uid 1000

$ sudo ifconfig -a|grep unicode|hexdump -C
00000000  75 6e 69 63 6f 64 65 c3  a9 20 4c 69 6e 6b 20 65  |unicode.. Link e|
00000010  6e 63 61 70 3a 45 74 68  65 72 6e 65 74 20 20 48  |ncap:Ethernet  H|
00000020  57 61 64 64 72 20 64 36  3a 30 38 3a 31 63 3a 65  |Waddr d6:08:1c:e|
00000030  30 3a 33 33 3a 30 36 20  20 0a                    |0:33:06  .|
0000003a

So in my setup (UTF-8 locale encoding), U+00E9 is encoded as {0xc3, 0xa9} (UTF-8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Thu May 19 12:09:58 2011
From: report at bugs.python.org (Christophe Devriese)
Date: Thu, 19 May 2011 10:09:58 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>


New submission from Christophe Devriese <christophe.devriese at gmail.com>:

The specific issue this is creating is that a malicious user could use this socket in a subprocess which is started from a library (ie. I'm using a .so, which calls fork/exec).

A second failure mode is starting a daemon from withing, say, a django application. Djano opens a TCP listening socket, then starts up a daemon to provide some sort of service in the background. The daemon keeps running and inherits the socket. Now you restart the django app.

It refuses to start ! Why ? Because the socket was inherited, the listening socket isn't actually closed, and this results in the socket being stuck in CLOSE_WAIT as long as the daemon is running.

It seems to me that it is almost never the case that you'd want a TCP listening socket to be preserved across exec, and not setting this flag should thus be considered a bug for 2 reasons :

1) it results in accidental disclosure of information that shouldn't be exposed in certain cases.
2) it can result in denial of service

Solution : 

update SocketServer.py :
  in the class TCPServer
  add the following 2 lines in __init__ after self.socket = socket( ...:
    flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
    fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)

----------
messages: 136273
nosy: Christophe.Devriese
priority: normal
severity: normal
status: open
title: TCP listening sockets created without FD_CLOEXEC flag
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Thu May 19 12:15:32 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 19 May 2011 10:15:32 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305800132.61.0.972273740586.issue12107@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/issue12107>
_______________________________________

From report at bugs.python.org  Thu May 19 13:36:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:36:10 +0000
Subject: [issue12108] test_packaging monkeypatches httplib
Message-ID: <1305804970.53.0.916990970269.issue12108@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: pitrou
priority: normal
severity: normal
status: open
title: test_packaging monkeypatches httplib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12108>
_______________________________________

From report at bugs.python.org  Thu May 19 13:36:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:36:44 +0000
Subject: [issue12109] test_packaging monkeypatches httplib
In-Reply-To: <1305805004.65.0.179982537275.issue12109@psf.upfronthosting.co.za>
Message-ID: <1305805004.65.0.179982537275.issue12109@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

======================================================================
ERROR: test_https (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 457, in test_https
    data = self.urlopen("https://localhost:%s/bizarre" % handler.port)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

======================================================================
ERROR: test_https_with_cafile (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 465, in test_https_with_cafile
    cafile=CERT_localhost)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

----------
assignee: tarek
components: Distutils2, Tests
messages: 136274
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging monkeypatches httplib
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12109>
_______________________________________

From report at bugs.python.org  Thu May 19 13:36:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:36:46 +0000
Subject: [issue12110] test_packaging monkeypatches httplib
In-Reply-To: <1305805006.32.0.311431989119.issue12110@psf.upfronthosting.co.za>
Message-ID: <1305805006.32.0.311431989119.issue12110@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

======================================================================
ERROR: test_https (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 457, in test_https
    data = self.urlopen("https://localhost:%s/bizarre" % handler.port)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

======================================================================
ERROR: test_https_with_cafile (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 465, in test_https_with_cafile
    cafile=CERT_localhost)
  File "D:\Buildslave\3.x.moore-windows\build\lib\test\test_urllib2_localnet.py", line 364, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 369, in open
    response = self._open(req, data)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 387, in _open
    '_open', req)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 347, in _call_chain
    result = func(*args)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1179, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "D:\Buildslave\3.x.moore-windows\build\lib\urllib\request.py", line 1116, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
TypeError: https_conn_wrapper() got an unexpected keyword argument 'check_hostname'

----------
assignee: tarek
components: Distutils2, Tests
messages: 136275
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging monkeypatches httplib
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12110>
_______________________________________

From report at bugs.python.org  Thu May 19 13:37:22 2011
From: report at bugs.python.org (Toni Mueller)
Date: Thu, 19 May 2011 11:37:22 +0000
Subject: [issue12111] email's use of __setitem__ is highly counterintuitive
In-Reply-To: <1305805042.77.0.328218985271.issue12111@psf.upfronthosting.co.za>
Message-ID: <1305805042.77.0.328218985271.issue12111@psf.upfronthosting.co.za>


New submission from Toni Mueller <tonimueller at users.sourceforge.net>:

email's usage of __setitem__ is highly counterintuitive to the point of being dangerous. The documented behaviour is (quote):


__setitem__(name, val)

    Add a header to the message with field name name and value val. The field is appended to the end of the message?s existing fields.

    Note that this does not overwrite or delete any existing header with the same name. If you want to ensure that the new header is the only one present in the message with field name name, delete the field first, e.g.:
...

(taken from http://docs.python.org/library/email.message.html )

The use case of *appending* a header of the same type (eg. a "Received:" header) should be performed by the add_header() method, or an extend_header() method, or something similar, and not by abusing the __setitem__ method. The current behaviour imho deviates extremely from the behaviour of similar libraries in all other programming languages that I'm aware of, and from the standard dict functionality, too. It makes it much too easy to have duplicate headers, esp., duplicate "To:" headers, resulting in mailbombing and information leakage. For the potential damage, this property of the library is highly under-advertised.

A side effect appears to be that trying to have your message headers set up in a unique fashion, probably the most frequent use case, one has to make sure to use each operator only once, or "decorate" everything with a del msg[myheader], as the operation is not idempotent.

----------
messages: 136276
nosy: tonimueller
priority: normal
severity: normal
status: open
title: email's use of __setitem__ is highly counterintuitive
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12111>
_______________________________________

From report at bugs.python.org  Thu May 19 13:37:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:37:34 +0000
Subject: [issue12110] test_packaging monkeypatches httplib
In-Reply-To: <1305805006.32.0.311431989119.issue12110@psf.upfronthosting.co.za>
Message-ID: <1305805054.38.0.83700920654.issue12110@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_packaging monkeypatches httplib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12110>
_______________________________________

From report at bugs.python.org  Thu May 19 13:39:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:39:29 +0000
Subject: [issue12108] test_packaging monkeypatches httplib
Message-ID: <1305805169.11.0.746919480456.issue12108@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/issue12108>
_______________________________________

From report at bugs.python.org  Thu May 19 13:39:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 11:39:36 +0000
Subject: [issue12109] test_packaging monkeypatches httplib
In-Reply-To: <1305805004.65.0.179982537275.issue12109@psf.upfronthosting.co.za>
Message-ID: <1305805176.62.0.397552064176.issue12109@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

$ grep -r https_conn_wrapper *
Lib/packaging/tests/test_command_upload_docs.py:146:        def https_conn_wrapper(*args):
Lib/packaging/tests/test_command_upload_docs.py:152:        upload_docs_mod.http.client.HTTPSConnection = https_conn_wrapper

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12109>
_______________________________________

From report at bugs.python.org  Thu May 19 13:46:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 11:46:56 +0000
Subject: [issue12109] test_packaging monkeypatches httplib
In-Reply-To: <1305805004.65.0.179982537275.issue12109@psf.upfronthosting.co.za>
Message-ID: <E1QN1gt-0002sS-E8@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 56aa0aca7186 by Tarek Ziade in branch 'default':
Issue #12109 fixing typo in packaging's test_command_upload_docs
http://hg.python.org/cpython/rev/56aa0aca7186

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12109>
_______________________________________

From report at bugs.python.org  Thu May 19 13:49:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 May 2011 11:49:07 +0000
Subject: [issue12111] email's use of __setitem__ is highly counterintuitive
In-Reply-To: <1305805042.77.0.328218985271.issue12111@psf.upfronthosting.co.za>
Message-ID: <1305805747.61.0.731863270462.issue12111@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a long-standing design choice in the email package.  If you want to advocate for changing it, please join the email-sig mailing list (see mail.python.org).  We are in the process of developing a new version, which will at least reject things like duplicate To headers.

I'm closing this issue since as things stand this is not something that is likely to change.  If you carry the day in a discussion on the email-sig, we can reopen the issue.  In any case it is a feature request, not a bug.

----------
components: +Library (Lib)
nosy: +r.david.murray
status: open -> closed
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12111>
_______________________________________

From report at bugs.python.org  Thu May 19 13:54:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 11:54:28 +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: <1305806068.46.0.0788802994526.issue12112@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The locale encoding is not portable, packaging should use UTF-8 instead.

Attached patch is a draft to workaround "LANG=C ./python -m test test_packaging" failures. I'm not sure that my test in Metadata.write_file() of packaging.metadata is a good idea.

Moreover, packaging should also maybe use the surrogateescape error handler, but I propose to decide that later and in another issue. We may use this error handler only to read files (like the Python makefile).

For write a complete patch, *all* calls to open() in Lib/packaging/* (including Lib/packaging/tests/*) should be checked.

distutils uses the locale encoding, which is UTF-8 on Mac OS X and most Linux setup (but never on Windows). But distutils cannot be fixed, whereas packaging is a new module and can be fixed.

----------
files: packaging_utf8.patch
keywords: patch
messages: 136280
nosy: haypo
priority: normal
severity: normal
status: open
title: The new packaging module should not use the locale encoding
versions: Python 3.3
Added file: http://bugs.python.org/file22028/packaging_utf8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 13:54:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 11:54:46 +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: <1305806086.57.0.53277470803.issue12112@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Library (Lib)
nosy: +eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 13:56:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 11:56: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: <1305806209.59.0.330255593246.issue12112@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #9561 (distutils: set encoding to utf-8 for input and output files) and #6011 (python doesn't build if prefix contains non-ascii characters).

If you are curious, read also #8611 (Python3 doesn't support locale different than utf8 and an non-ASCII path (POSIX)) and #9425 (Rewrite import machinery to work with unicode paths).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 14:01:48 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 12:01:48 +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: <1305806508.85.0.817922959717.issue12112@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Looks good, please commit this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 14:09:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 12:09:41 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ ./python -m test -Fv -unetwork test_packaging 

[...]

======================================================================
ERROR: test_download (packaging.tests.test_pypi_dist.TestDistInfo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/packaging/tests/pypi_server.py", line 68, in wrapped
    func(server=server, *args, **kwargs)
  File "/home/antoine/cpython/default/Lib/packaging/tests/test_pypi_dist.py", line 132, in test_download
    dist.download(self.mkdtemp())
  File "/home/antoine/cpython/default/Lib/packaging/pypi/dist.py", line 306, in download
    self._check_md5(filename)
  File "/home/antoine/cpython/default/Lib/packaging/pypi/dist.py", line 339, in _check_md5
    % (hashval.hexdigest(), expected_hashval))
packaging.pypi.errors.HashDoesNotMatch: got 8ae6ff9df26ff04232189724d520a17c instead of fe18804c5b722ff024cabdf514924fc4

======================================================================
FAIL: test_hooks_get_run (packaging.tests.test_dist.DistributionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/packaging/tests/test_dist.py", line 234, in test_hooks_get_run
    'post-test_dist'])
AssertionError: Lists differ: ['finalize', 'pre-test_dist', ... != ['finalize', 'pre-test_dist', ...

First list contains 4 additional elements.
First extra element 4:
finalize

+ ['finalize', 'pre-test_dist', 'run', 'post-test_dist']
- ['finalize',
-  'pre-test_dist',
-  'run',
-  'post-test_dist',
-  'finalize',
-  'pre-test_dist',
-  'run',
-  'post-test_dist']

----------------------------------------------------------------------

----------
assignee: tarek
components: Distutils2, Tests
messages: 136283
nosy: alexis, eric.araujo, pitrou, tarek
priority: high
severity: normal
stage: needs patch
status: open
title: test_packaging fails when run twice
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Thu May 19 14:35:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 12:35:02 +0000
Subject: [issue12109] test_packaging monkeypatches httplib
In-Reply-To: <1305805004.65.0.179982537275.issue12109@psf.upfronthosting.co.za>
Message-ID: <1305808502.98.0.497026607341.issue12109@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good here, thank you :)

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12109>
_______________________________________

From report at bugs.python.org  Thu May 19 14:46:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 12:46:39 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <E1QN2cg-00007u-D4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3e0500881003 by Tarek Ziade in branch 'default':
Issue #12113: make sure generated module is not reused on a second run
http://hg.python.org/cpython/rev/3e0500881003

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Thu May 19 15:05:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 13:05:02 +0000
Subject: [issue12114] packaging.util._find_exe_version(): potential deadlock
In-Reply-To: <1305810302.14.0.0379253224029.issue12114@psf.upfronthosting.co.za>
Message-ID: <1305810302.14.0.0379253224029.issue12114@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code does deadlock if the subprocess writes a lot of output to stdout and stderr:

    pipe = Popen(cmd, shell=True, stdout=PIPE, stderr=PIPE)
    try:
        stdout, stderr = pipe.stdout.read(), pipe.stderr.read()
    finally:
        pipe.stdout.close()
        pipe.stderr.close()

Popen.communicate() should be used to avoid the issue.

Attached patch uses the .communicate() method and the context manager syntax (with).

----------
components: Library (Lib)
files: packaging_popen_communicate.patch
keywords: patch
messages: 136286
nosy: haypo, tarek
priority: normal
severity: normal
status: open
title: packaging.util._find_exe_version(): potential deadlock
versions: Python 3.3
Added file: http://bugs.python.org/file22029/packaging_popen_communicate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12114>
_______________________________________

From report at bugs.python.org  Thu May 19 15:07:49 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 13:07:49 +0000
Subject: [issue12115] some tests need to be skipped on threadless systems
In-Reply-To: <1305810469.1.0.258347676504.issue12115@psf.upfronthosting.co.za>
Message-ID: <1305810469.1.0.258347676504.issue12115@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

======================================================================
ERROR: packaging.tests.test_command_upload_docs (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/case.py", line 407, in _executeTestPart
    function()
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/loader.py", line 32, in testFailure
    raise exception
ImportError: Failed to import test module: packaging.tests.test_command_upload_docs
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/loader.py", line 257, in _find_tests
    module = self._get_module_from_name(name)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/unittest/loader.py", line 235, in _get_module_from_name
    __import__(name)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/packaging/tests/test_command_upload_docs.py", line 14, in <module>
    from packaging.tests.pypi_server import PyPIServerTestCase
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/packaging/tests/pypi_server.py", line 36, in <module>
    import threading
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 437, in load_module
    return self._load_module(fullname)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 141, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/_bootstrap.py", line 342, in _load_module
    exec(code_object, module.__dict__)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

----------
assignee: tarek
components: Library (Lib)
messages: 136287
nosy: alexis, tarek
priority: normal
severity: normal
status: open
title: some tests need to be skipped on threadless systems
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12115>
_______________________________________

From report at bugs.python.org  Thu May 19 15:17:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 13:17:29 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1305811049.05.0.780283292958.issue12113@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Still fails on test_download.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Thu May 19 15:18:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 13:18:47 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <E1QN37l-0003ju-SI@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cc5cfeaa4a8d by Victor Stinner in branch 'default':
Issue #10419, issue #6011: port 6ad356525381 fix from distutils to packaging
http://hg.python.org/cpython/rev/cc5cfeaa4a8d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Thu May 19 15:19:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 13:19:26 +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: <1305811166.48.0.834377838434.issue12112@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I ported a distutils fix (for non-ASCII path) into packaging:

New changeset cc5cfeaa4a8d by Victor Stinner in branch 'default':
Issue #10419, issue #6011: port 6ad356525381 fix from distutils to packaging
http://hg.python.org/cpython/rev/cc5cfeaa4a8d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 15:24:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 13:24:01 +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: <1305811441.8.0.680590728546.issue12112@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+        if not isinstance(fileobject, StringIO):
+            encoding = codecs.lookup(fileobject.encoding).name

IMO you should try to get the "encoding" attribute and silence the AttributeError instead.

(also, I'm not even sure why you're adding this check)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 15:25:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 13:25:47 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1305811547.41.0.730040576073.issue12113@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also, the hash value is different every time:

packaging.pypi.errors.HashDoesNotMatch: got 043840092b5baf155fc94a77319c5f44 instead of fe18804c5b722ff024cabdf514924fc4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Thu May 19 15:27:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 13:27:45 +0000
Subject: [issue12115] some tests need to be skipped on threadless systems
In-Reply-To: <1305810469.1.0.258347676504.issue12115@psf.upfronthosting.co.za>
Message-ID: <E1QN3GS-0004bn-0F@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2c01bda139a7 by Tarek Ziade in branch 'default':
Issue #12115: skipping all tests that need threading under a threadless environment
http://hg.python.org/cpython/rev/2c01bda139a7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12115>
_______________________________________

From report at bugs.python.org  Thu May 19 15:28:40 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 13:28:40 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1305811720.83.0.581171840505.issue12113@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

my commit fixed only the first issue. the second one is a separate issue that needs more investigation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Thu May 19 16:16:48 2011
From: report at bugs.python.org (Jay Parlar)
Date: Thu, 19 May 2011 14:16:48 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1305814608.73.0.686269989384.issue12077@psf.upfronthosting.co.za>


Jay Parlar <parlar at gmail.com> added the comment:

Another problem is that the examples and text in the section "Functions and Methods" is no longer correct in 3.x. Namely the the references to unbound methods, and the example showing an unbound method being returned when accessing a method of a class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Thu May 19 16:22:08 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 19 May 2011 14:22:08 +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: <1305814928.43.0.68475308233.issue12112@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/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 16:27:32 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 19 May 2011 14:27:32 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1305815252.96.0.185050201172.issue12113@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/issue12113>
_______________________________________

From report at bugs.python.org  Thu May 19 16:27:52 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 19 May 2011 14:27:52 +0000
Subject: [issue12114] packaging.util._find_exe_version(): potential deadlock
In-Reply-To: <1305810302.14.0.0379253224029.issue12114@psf.upfronthosting.co.za>
Message-ID: <1305815272.83.0.0197165830285.issue12114@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/issue12114>
_______________________________________

From report at bugs.python.org  Thu May 19 18:04:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 16:04:46 +0000
Subject: [issue12116] io.Buffer*.seek() doesn't seek if "seeking leaves us
	inside the current buffer"
In-Reply-To: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>
Message-ID: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Example:

with open("setup.py", "rb") as f:
    # read smaller than the file size to fill the readahead buffer
    f.read(1)
    # seek doesn't seek
    f.seek(0)
    print("f pos=", f.tell())
    print("f.raw pos=", f.raw.tell())

Output:

f pos= 0
f.raw pos= 4096

I expect f.raw.tell() to be 0.

Extract of Modules/_io/buffered.c:

    if (whence != 2 && self->readable) {
        Py_off_t current, avail;
        /* Check if seeking leaves us inside the current buffer,
           so as to return quickly if possible. Also, we needn't take the
           lock in this fast path.
           Don't know how to do that when whence == 2, though. */
        /* NOTE: RAW_TELL() can release the GIL but the object is in a stable
           state at this point. */
        current = RAW_TELL(self);
        avail = READAHEAD(self);
        printf("current=%"  PY_PRIdOFF ", avail=%"  PY_PRIdOFF "\n", current, avail);
        if (avail > 0) {
            Py_off_t offset;
            if (whence == 0)
                offset = target - (current - RAW_OFFSET(self));
            else
                offset = target;
            printf("offset=%"  PY_PRIdOFF "\n", offset);
            if (offset >= -self->pos && offset <= avail) {
                printf("NO SEEK!\n");
                self->pos += offset;
                return PyLong_FromOff_t(current - avail + offset);
            }
        }
    }

I found this weird behaviour when trying to understand why:

        with open("setup.py", 'rb') as f:
            encoding, lines = tokenize.detect_encoding(f.readline)
        with open("setup.py", 'r', encoding=encoding) as f:
            imp.load_module("setup", f, "setup.py", (".py", "r", imp.PY_SOURCE))

is different than:

        with tokenize.open("setup.py") as f:
            imp.load_module("setup", f, "setup.py", (".py", "r", imp.PY_SOURCE))

imp.load_module() clones the file using something like fd = os.dup(f.fileno()); clone = os.fdopen(fd, "r").

For tokenizer.open(), a workaround is to replace:
   buffer.seek(0)
by
   buffer.seek(0); buffer.raw.seek(0)

----------
components: IO
messages: 136296
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: io.Buffer*.seek() doesn't seek if "seeking leaves us inside the current buffer"
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12116>
_______________________________________

From report at bugs.python.org  Thu May 19 18:07:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 16:07:20 +0000
Subject: [issue12116] io.Buffer*.seek() doesn't seek if "seeking leaves us
	inside the current buffer"
In-Reply-To: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>
Message-ID: <1305821240.53.0.569865797811.issue12116@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: _pyio.BufferedReader(), _pyio.BufferedWriter(), _pyio.BufferedRandom() don't use this optimization. They might be patched too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12116>
_______________________________________

From report at bugs.python.org  Thu May 19 18:16:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:16:42 +0000
Subject: [issue12116] io.Buffer*.seek() doesn't seek if "seeking leaves us
	inside the current buffer"
In-Reply-To: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>
Message-ID: <1305821802.3.0.95233616497.issue12116@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is by design.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12116>
_______________________________________

From report at bugs.python.org  Thu May 19 18:18:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:18:06 +0000
Subject: [issue12117] test_importlib failure
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following failure under a fresh checkout:

======================================================================
ERROR: test_file_from_empty_string_dir (importlib.test.source.test_file_loader.SimpleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/importlib/test/source/test_file_loader.py", line 129, in test_file_from_empty_string_dir
    shutil.rmtree(pycache)
  File "/home/antoine/t/cpython/Lib/shutil.py", line 270, in rmtree
    onerror(os.listdir, path, sys.exc_info())
  File "/home/antoine/t/cpython/Lib/shutil.py", line 268, in rmtree
    names = os.listdir(path)
OSError: [Errno 2] No such file or directory: '__pycache__'

----------
assignee: brett.cannon
components: Tests
messages: 136299
nosy: barry, brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_importlib failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Thu May 19 18:19:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:19:45 +0000
Subject: [issue12118] test_imp failure
In-Reply-To: <1305821985.21.0.668805686693.issue12118@psf.upfronthosting.co.za>
Message-ID: <1305821985.21.0.668805686693.issue12118@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following failure under a fresh checkout:

======================================================================
ERROR: test_issue5604 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_imp.py", line 163, in test_issue5604
    temp_mod_name, imp.cache_from_source(temp_mod_name + '.py'))
IOError: [Errno 2] No such file or directory

----------
components: Tests
messages: 136300
nosy: barry, brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_imp failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12118>
_______________________________________

From report at bugs.python.org  Thu May 19 18:20:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:20:53 +0000
Subject: [issue12119] test_distutils failure
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following failure under a fresh checkout:

======================================================================
FAIL: test_package_data (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/distutils/tests/test_build_py.py", line 61, in test_package_data
    self.assertTrue("__init__.pyc" in files)
AssertionError: False is not true

----------
assignee: tarek
components: Distutils, Tests
messages: 136301
nosy: eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: test_distutils failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Thu May 19 18:20:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:20:59 +0000
Subject: [issue12119] test_distutils failure
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1305822059.12.0.436912691863.issue12119@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Thu May 19 18:22:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:22:08 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following failure under a fresh checkout:

======================================================================
FAIL: test_package_data (packaging.tests.test_command_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/packaging/tests/test_command_build_py.py", line 64, in test_package_data
    self.assertIn("__init__.pyc", files)
AssertionError: '__init__.pyc' not found in ['README.txt', '__init__.py']

----------
assignee: tarek
components: Distutils2, Tests
messages: 136302
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: test_packaging failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 18:22:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:22:58 +0000
Subject: [issue12121] test_packaging failure when ssl is not available
In-Reply-To: <1305822178.04.0.171095491628.issue12121@psf.upfronthosting.co.za>
Message-ID: <1305822178.04.0.171095491628.issue12121@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following failure when the ssl module is not available:

======================================================================
ERROR: test_https_connection (packaging.tests.test_command_upload_docs.UploadDocsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/packaging/tests/test_command_upload_docs.py", line 151, in test_https_connection
    orig_https = upload_docs_mod.http.client.HTTPSConnection
AttributeError: 'module' object has no attribute 'HTTPSConnection'

----------
assignee: tarek
components: Distutils2, Tests
messages: 136303
nosy: alexis, eric.araujo, pitrou, tarek
priority: high
severity: normal
stage: needs patch
status: open
title: test_packaging failure when ssl is not available
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12121>
_______________________________________

From report at bugs.python.org  Thu May 19 18:25:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:25:02 +0000
Subject: [issue12122] test_runpy failure
In-Reply-To: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>
Message-ID: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following failures in a fresh checkout:

======================================================================
ERROR: test_explicit_relative_import (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 283, in test_explicit_relative_import
    self._check_relative_imports(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 257, in _check_relative_imports
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_main_relative_import (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 288, in test_main_relative_import
    self._check_relative_imports(depth, "__main__")
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 257, in _check_relative_imports
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_run_module (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 273, in test_run_module
    self._check_module(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 177, in _check_module
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_run_package (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 278, in test_run_package
    self._check_package(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 201, in _check_package
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory


Here is the test output:

test_run_code (test.test_runpy.RunModuleCodeTest) ... ok
test_run_module_code (test.test_runpy.RunModuleCodeTest) ... ok
test_explicit_relative_import (test.test_runpy.RunModuleTest) ... Testing relative imports at depth: 2
  Package tree in: /tmp/tmpmruwyg
  Updated sys.path: /tmp/tmpmruwyg
  Next level in: /tmp/tmpmruwyg/__runpy_pkg__
  Created: /tmp/tmpmruwyg/__runpy_pkg__/__init__.py
  Next level in: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__
  Created: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__/__init__.py
  Created: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__/runpy_test.py
  Added sibling module: /tmp/tmpmruwyg/__runpy_pkg__/__runpy_pkg__/sibling.py
  Added uncle package: /tmp/tmpmruwyg/__runpy_pkg__/uncle
  Added cousin package: /tmp/tmpmruwyg/__runpy_pkg__/uncle/cousin
  Added nephew module: /tmp/tmpmruwyg/__runpy_pkg__/uncle/cousin/nephew.py
Running from source: __runpy_pkg__.__runpy_pkg__.runpy_test
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_invalid_names (test.test_runpy.RunModuleTest) ... ok
test_library_module (test.test_runpy.RunModuleTest) ... ok
test_main_relative_import (test.test_runpy.RunModuleTest) ... Testing main relative imports at depth: 2
  Package tree in: /tmp/tmp39sx5n
  Updated sys.path: /tmp/tmp39sx5n
  Next level in: /tmp/tmp39sx5n/__runpy_pkg__
  Created: /tmp/tmp39sx5n/__runpy_pkg__/__init__.py
  Next level in: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__
  Created: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__/__init__.py
  Created: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__/runpy_test.py
  Added sibling module: /tmp/tmp39sx5n/__runpy_pkg__/__runpy_pkg__/sibling.py
  Added uncle package: /tmp/tmp39sx5n/__runpy_pkg__/uncle
  Added cousin package: /tmp/tmp39sx5n/__runpy_pkg__/uncle/cousin
  Added nephew module: /tmp/tmp39sx5n/__runpy_pkg__/uncle/cousin/nephew.py
Running from source: __runpy_pkg__.__runpy_pkg__.runpy_test
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_run_module (test.test_runpy.RunModuleTest) ... Testing package depth: 0
  Package tree in: /tmp/tmpy4y7in
  Updated sys.path: /tmp/tmpy4y7in
  Created: /tmp/tmpy4y7in/runpy_test.py
Running from source: runpy_test
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_run_package (test.test_runpy.RunModuleTest) ... Testing package depth: 1
  Package tree in: /tmp/tmp_7dx_4
  Updated sys.path: /tmp/tmp_7dx_4
  Next level in: /tmp/tmp_7dx_4/__runpy_pkg__
  Created: /tmp/tmp_7dx_4/__runpy_pkg__/__init__.py
  Created: /tmp/tmp_7dx_4/__runpy_pkg__/__main__.py
Running from source: __runpy_pkg__
  Removed sys.modules entries
  Removed sys.path entry
  Removed package tree
ERROR
test_basic_script (test.test_runpy.RunPathTest) ... ok
test_directory (test.test_runpy.RunPathTest) ... ok
test_directory_compiled (test.test_runpy.RunPathTest) ... ok
test_directory_error (test.test_runpy.RunPathTest) ... ok
test_main_recursion_error (test.test_runpy.RunPathTest) ... ok
test_script_compiled (test.test_runpy.RunPathTest) ... ok
test_zipfile (test.test_runpy.RunPathTest) ... ok
test_zipfile_compiled (test.test_runpy.RunPathTest) ... ok
test_zipfile_error (test.test_runpy.RunPathTest) ... ok

----------
assignee: ncoghlan
components: Tests
messages: 136304
nosy: barry, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_runpy failure
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12122>
_______________________________________

From report at bugs.python.org  Thu May 19 18:26:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:26:48 +0000
Subject: [issue12123] test_import failures
In-Reply-To: <1305822408.68.0.563434237022.issue12123@psf.upfronthosting.co.za>
Message-ID: <1305822408.68.0.563434237022.issue12123@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get the following failures under a fresh checkout:

======================================================================
ERROR: test_file_to_source (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 253, in test_file_to_source
    make_legacy_pyc(source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test___cached___legacy_pyc (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 584, in test___cached___legacy_pyc
    pyc_file = make_legacy_pyc(self.source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_missing_source_legacy (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 564, in test_missing_source_legacy
    pyc_file = make_legacy_pyc(self.source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
FAIL: test_execute_bit_not_copied (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 112, in test_execute_bit_not_copied
    self.fail("__import__ did not result in creation of "
AssertionError: __import__ did not result in creation of either a .pyc or .pyo file

======================================================================
FAIL: test_import_pyc_path (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 531, in test_import_pyc_path
    self.assertTrue(os.path.exists('__pycache__'))
AssertionError: False is not true

======================================================================
FAIL: test_missing_source (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 552, in test_missing_source
    self.assertTrue(os.path.exists(pyc_file))
AssertionError: False is not true

======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 543, in test_unwritable_directory
    self.assertTrue(os.path.exists('__pycache__'))
AssertionError: False is not true

----------
components: Tests
messages: 136305
nosy: barry, brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_import failures
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12123>
_______________________________________

From report at bugs.python.org  Thu May 19 18:39:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 16:39:34 +0000
Subject: [issue12116] io.Buffer*.seek() doesn't seek if "seeking leaves us
	inside the current buffer"
In-Reply-To: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>
Message-ID: <1305823174.81.0.878952993902.issue12116@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

And how can I seek the raw file to zero?

Using buffer.raw.seek(0), buffer.tell() becomes inconsistent:

$ ./python 
Python 3.2.1b1 (3.2:bd5e4d8c8080, May 15 2011, 10:22:54) 
>>> buffer=open('setup.py', 'rb')
>>> buffer.read(1)
>>> buffer.tell()
1
>>> buffer.raw.tell()
4096
>>> buffer.raw.seek(0)
0
>>> buffer.raw.tell()
0
>>> buffer.tell()
-4095

Same problem with os.lseek():

$ ./python 
Python 3.2.1b1 (3.2:bd5e4d8c8080, May 15 2011, 10:22:54) 
>>> import os
>>> buffer=open("setup.py", "rb")
>>> buffer.read(1)
>>> os.lseek(buffer.fileno(), 0, 0)
0
>>> buffer.raw.tell()
0
>>> buffer.tell()
-4095

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12116>
_______________________________________

From report at bugs.python.org  Thu May 19 18:42:54 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 19 May 2011 16:42:54 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1305823374.24.0.840488149346.issue1006238@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

What is the current status of this patch? What is missing to apply it upstream?

----------
nosy: +wrobell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Thu May 19 18:43:45 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 16:43:45 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305823425.54.0.631009740245.issue12120@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

on it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 18:44:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:44:18 +0000
Subject: [issue12116] io.Buffer*.seek() doesn't seek if "seeking leaves us
	inside the current buffer"
In-Reply-To: <1305821086.44.0.699484480177.issue12116@psf.upfronthosting.co.za>
Message-ID: <1305823458.47.0.627497948983.issue12116@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Simple: you are not supposed to use the raw file if you wrapped it inside a buffered file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12116>
_______________________________________

From report at bugs.python.org  Thu May 19 18:48:18 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 16:48:18 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305823698.28.0.605102714749.issue12120@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I cannot reproduce this. there's exactly the same test in distutils, so I am wondering why it passes there and not in packaging for you.

Any special way to run the tests ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 18:50:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 16:50:23 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305823698.28.0.605102714749.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305823818.3500.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I cannot reproduce this. there's exactly the same test in distutils,
> so I am wondering why it passes there and not in packaging for you.

It doesn't. Have you seen http://bugs.python.org/issue12119 ?

> Any special way to run the tests ?

No. This is a fresh checkout on a fresh Linux install. Only zlib is
available (not bz2 etc.).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 18:50:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 16:50:26 +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: <E1QN6Qa-0006st-O0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fe740c1cee02 by Victor Stinner in branch 'default':
Issue #12112: packaging reads and writes setup.cfg using UTF-8
http://hg.python.org/cpython/rev/fe740c1cee02

New changeset 01d61096140a by Victor Stinner in branch 'default':
Issue #12112: packaging reads/writes metadata using UTF-8
http://hg.python.org/cpython/rev/01d61096140a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 18:52:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 16:52:58 +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: <1305823978.17.0.67958029041.issue12112@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What is the MainProgram.inspect_file() function in packaging.create? Which kind of file should it process? => What is the encoding of the input files?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 18:54:26 2011
From: report at bugs.python.org (Danek Duvall)
Date: Thu, 19 May 2011 16:54:26 +0000
Subject: [issue1298835] vendor-packages directory.
Message-ID: <1305824066.62.0.799476994572.issue1298835@psf.upfronthosting.co.za>


Danek Duvall <duvall at comfychair.org> added the comment:

So this has come up again within the Solaris group.  Since Rich's original request, we've been using a vendor-packages.pth file in the site-packages directory, which enables the vendor-packages directory.  However, I have a concern that this would completely disappear when Py_NoSiteFlag is enabled.  I would like to run the interpreter with -SE on all system-provided scripts, so that modules installed by the user in a private PYTHONPATH or in site-packages via easy_install (or similar) don't inadvertently interpose on system-provided modules which are the ones we've tested against.

I'm attaching a patch (against 2.6.4; sorry, haven't looked at anything newer yet) that modifies pythonrun.c to add initvendor() as a parallel with initmain() and initsite(), and is always run, regardless of Py_NoSiteFlag, but inserts vendor-packages after site-packages for when the user or a script is okay with the potential interposition.

If support for vendor-packages is being considered in general, I'd like to address the request for a rationale that has been brought up a handful of times before.  Specifically, distro vendors (such as ourselves) want to be able to deliver non-core python modules -- some written ourselves, some available from the community at large.  If we do that in the canonical site-packages directory, then those modules are at risk of being overwritten by local administrators installing python packages as they normally would.  This means that system programs -- including critical ones on Solaris, such as the packaging system -- might suddenly stop working.  If we separate the vendor space from the end-user space, then local admins can do anything they want without fear of breaking the system.  And if they really want to replace the vendor-supplied modules, then they can either go to the lengths of making the modules install in vendor-packages, or build using the same mechanisms we do (which for almost all the python we ship are still open-source) and install the resulting (system, not python) package.

I'd love feedback on my patch, regardless.

----------
nosy: +dhduvall
Added file: http://bugs.python.org/file22030/vps.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298835>
_______________________________________

From report at bugs.python.org  Thu May 19 19:04:55 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 17:04:55 +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: <1305824695.57.0.739973807986.issue12112@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That's not used anymore, I am going to strip it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 19:10:23 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 May 2011 17:10:23 +0000
Subject: [issue12122] test_runpy failure
In-Reply-To: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>
Message-ID: <1305825023.57.0.506302610905.issue12122@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It still works fine for me (as do test_imp, test_import and test_importlib).

Did you provide any arguments to ./configure, or provide any interesting options to regrtest to get it to fail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12122>
_______________________________________

From report at bugs.python.org  Thu May 19 19:13:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 May 2011 17:13:16 +0000
Subject: [issue12122] test_runpy failure
In-Reply-To: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>
Message-ID: <1305825196.26.0.427994441439.issue12122@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oh, that's the other question - is there any chance you are passing -B or have PYTHONDONTWRITEBYTECODE set? (I'm not sure that would affect make_legacy_pyc, but all the errors you posted relate to unexpectedly absent pyc files and directories)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12122>
_______________________________________

From report at bugs.python.org  Thu May 19 19:29:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 17:29:07 +0000
Subject: [issue12122] test_runpy failure
In-Reply-To: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>
Message-ID: <1305826147.25.0.650544008173.issue12122@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, PYTHONDONTWRITEBYTECODE seems set by default on this Linux install... Ouch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12122>
_______________________________________

From report at bugs.python.org  Thu May 19 19:30:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 17:30:59 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305826259.63.0.0136471127997.issue12120@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is due to PYTHONDONTWRITEBYTECODE being set. Not sure this is worth fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 19:31:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 17:31:04 +0000
Subject: [issue12123] test_import failures
In-Reply-To: <1305822408.68.0.563434237022.issue12123@psf.upfronthosting.co.za>
Message-ID: <1305826264.87.0.238124404832.issue12123@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is due to PYTHONDONTWRITEBYTECODE being set. Not sure this is worth fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12123>
_______________________________________

From report at bugs.python.org  Thu May 19 19:31:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 17:31:12 +0000
Subject: [issue12119] test_distutils failure
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1305826272.92.0.810872153566.issue12119@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is due to PYTHONDONTWRITEBYTECODE being set. Not sure this is worth fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Thu May 19 19:31:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 17:31:16 +0000
Subject: [issue12118] test_imp failure
In-Reply-To: <1305821985.21.0.668805686693.issue12118@psf.upfronthosting.co.za>
Message-ID: <1305826276.78.0.289743249328.issue12118@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is due to PYTHONDONTWRITEBYTECODE being set. Not sure this is worth fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12118>
_______________________________________

From report at bugs.python.org  Thu May 19 19:31:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 17:31:23 +0000
Subject: [issue12117] test_importlib failure
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305826283.36.0.76291027184.issue12117@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is due to PYTHONDONTWRITEBYTECODE being set. Not sure this is worth fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Thu May 19 19:44:16 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Thu, 19 May 2011 17:44:16 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305827056.77.0.50778904631.issue12120@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

a well, we can skip that pyc test in case PYTHONDONTWRITEBYTECODE is set, thanks !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 19:51:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 17:51:45 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305827056.77.0.50778904631.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305827502.3482.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> a well, we can skip that pyc test in case PYTHONDONTWRITEBYTECODE is set, thanks !

It's better to test sys.flags.dont_write_bytecode, actually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 19:56:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 17:56:24 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <E1QN7SR-0004Nj-5X@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9d1fb6a9104b by Tarek Ziade in branch 'default':
Issue #12120, Issue #12119: tests were missing a sys.dont_write_bytecode check
http://hg.python.org/cpython/rev/9d1fb6a9104b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Thu May 19 20:38:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 19 May 2011 18:38:54 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305830334.71.0.500185714068.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch adding O_CLOEXEC to the os module, with test. This patch makes it possible to open and set a FD CLOEXEC atomically.
O_CLOEXEC is part of POSIX.1-2008, supported by the Linux kernel since 2.6.23 and has been committed recently to FreeBSD.
Note that I'm not sure that adding this flag to built-in open() is necessarily a good idea, because it's not portable and low-level.
The same functionality can be more or less achieved with:
f = os.fdopen(os.open('/etc/fstab', os.O_RDONLY|os.O_CLOEXEC))

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file22031/os_cloexec.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Thu May 19 21:15:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 19:15:32 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305832532.67.0.252255366596.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using spawn_python() to check that os.O_CLOEXEC flag is correctly set seems overkill. Why not just testing fcntl.fcntl(f.fileno(), fcntl.F_GETFL) & FD_CLOEXEC)? I don't think that there are OSes with O_CLOEXEC but without fcntl(F_GETFL).

> Note that I'm not sure that adding this flag to built-in open()
> is necessarily a good idea

I agree.

open() documentation may explain the os.fdopen(os.open()) "trick" to use low-level options like O_SYNC or O_CLOEXEC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Thu May 19 21:18:53 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 May 2011 19:18:53 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305832733.19.0.0269599204685.issue12105@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

+1 for the patch!
Note that fdopen is now a simple call to open(), so theses lines are equivalent:

python2.7:   open(filename, 're')
python3.3:   open(os.open(filename, os.O_RDONLY|os.O_CLOEXEC))

----------
resolution:  -> accepted
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Thu May 19 21:45:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 19:45:26 +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: <E1QN99w-0005pR-Q6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a636cb1b7f84 by Victor Stinner in branch 'default':
Issue #12112: fix the encoding of setup.py in the packaging module
http://hg.python.org/cpython/rev/a636cb1b7f84

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12112>
_______________________________________

From report at bugs.python.org  Thu May 19 21:45:52 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 19 May 2011 19:45:52 +0000
Subject: [issue12104] os.path.join('/some/path',
	'') adds extra slash at end of result
In-Reply-To: <1305745526.57.0.545420875857.issue12104@psf.upfronthosting.co.za>
Message-ID: <1305834352.64.0.549530116609.issue12104@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This is intentional. See the implementation of join in Lib/posixpath.py and the Windows implementation in Lib/ntpath.py which also includes a comment explaining why.

# path is not empty and does not end with a backslash,
# but b is empty; since, e.g., split('a/') produces
# ('a', ''), it's best if join() adds a backslash in
# this case.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12104>
_______________________________________

From report at bugs.python.org  Thu May 19 21:52:11 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 19 May 2011 19:52:11 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305834731.61.0.738140491204.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

MS Connect is apparently only for projects under active development, not mature, released products. I've posted to the MSDN forums, where with my MSDN account, I can expect priority support from MS personnel.

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/93ebb061-d952-4650-b15c-30548a6649a8

I hope this helps resolve the issue at its source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Thu May 19 22:23:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 May 2011 20:23:50 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305836630.05.0.404990700508.issue12107@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +charles-francois.natali, gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Thu May 19 22:34:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 19 May 2011 20:34:20 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305832532.67.0.252255366596.issue12105@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=mHeNQeixwPEK08Y5QJ1BZ8DhF+g@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> Using spawn_python() to check that os.O_CLOEXEC flag is correctly set seems
> overkill. Why not just testing fcntl.fcntl(f.fileno(), fcntl.F_GETFL) &
> FD_CLOEXEC)?

Because I couldn't find a place where the CLOEXEC flag was fully
tested (I mean, checking in the child process that the FD was
correctly closed), so I took the opportunity to test it thoroughly
here.
But you're right it's maybe a little bit overkill, so here's a patch
using just F_GETFL. Pick up whichever you like.

>> Note that I'm not sure that adding this flag to built-in open()
>> is necessarily a good idea
>
> I agree.
>

OK.

> open() documentation may explain the os.fdopen(os.open()) "trick" to use
> low-level options like O_SYNC or O_CLOEXEC.
>

Why not, but I leave it to someone more comfortable with documentation
than me :-)

----------
Added file: http://bugs.python.org/file22032/os_cloexec_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________
-------------- next part --------------
diff -r 9d1fb6a9104b Doc/library/os.rst
--- a/Doc/library/os.rst	Thu May 19 19:56:12 2011 +0200
+++ b/Doc/library/os.rst	Thu May 19 22:21:09 2011 +0200
@@ -1298,6 +1298,7 @@
           O_NOCTTY
           O_SHLOCK
           O_EXLOCK
+          O_CLOEXEC
 
    These constants are only available on Unix.
 
diff -r 9d1fb6a9104b Lib/test/test_posix.py
--- a/Lib/test/test_posix.py	Thu May 19 19:56:12 2011 +0200
+++ b/Lib/test/test_posix.py	Thu May 19 22:21:09 2011 +0200
@@ -9,6 +9,7 @@
 import sys
 import time
 import os
+import fcntl
 import pwd
 import shutil
 import stat
@@ -307,6 +308,12 @@
                 fp1.close()
                 fp2.close()
 
+    @unittest.skipUnless(hasattr(os, 'O_CLOEXEC'), "needs os.O_CLOEXEC")
+    def test_oscloexec(self):
+        fd = os.open(support.TESTFN, os.O_RDONLY|os.O_CLOEXEC)
+        self.addCleanup(os.close, fd)
+        self.assertTrue(fcntl.fcntl(fd, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
+
     def test_osexlock(self):
         if hasattr(posix, "O_EXLOCK"):
             fd = os.open(support.TESTFN,
diff -r 9d1fb6a9104b Modules/posixmodule.c
--- a/Modules/posixmodule.c	Thu May 19 19:56:12 2011 +0200
+++ b/Modules/posixmodule.c	Thu May 19 22:21:09 2011 +0200
@@ -9783,6 +9783,9 @@
 #ifdef PRIO_USER
     if (ins(d, "PRIO_USER", (long)PRIO_USER)) return -1;
 #endif
+#ifdef O_CLOEXEC
+    if (ins(d, "O_CLOEXEC", (long)O_CLOEXEC)) return -1;
+#endif
 /* posix - constants for *at functions */
 #ifdef AT_SYMLINK_NOFOLLOW
         if (ins(d, "AT_SYMLINK_NOFOLLOW", (long)AT_SYMLINK_NOFOLLOW)) return -1;

From report at bugs.python.org  Thu May 19 22:42:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 20:42:05 +0000
Subject: [issue12124] python -m test test_packaging test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

"python -m test test_packaging test_zipimport" fails with:

======================================================================
FAIL: testAFakeZlib (test.test_zipimport.CompressedZipImportTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/HG/cpython/Lib/test/test_zipimport.py", line 130, in testAFakeZlib
    self.fail("expected test to raise ImportError")
AssertionError: expected test to raise ImportError

The problem is that the zipimport module keeps a reference to zlib.decompress() which "makes zlib.decompress immortal": see get_decompress_func() in zipimport.c.

Attached patch replaces the borrowed reference by a classic reference to allow to unload zlib.

I don't think that it makes zipimport slower: it calls PyImport_ImportModuleNoBlock("io") and PyObject_GetAttrString(zlib, "decompress") each time instead of just once, but PyImport_ImportModuleNoBlock() is just a lookup in a dict (if the zlib module is not unloaded between two calls to get_data()).

----------
components: Extension Modules, Tests
files: zipimport_get_data.patch
keywords: patch
messages: 136334
nosy: haypo, tarek
priority: normal
severity: normal
status: open
title: python -m test test_packaging test_zipimport failure
versions: Python 3.3
Added file: http://bugs.python.org/file22033/zipimport_get_data.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12124>
_______________________________________

From report at bugs.python.org  Thu May 19 22:54:19 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 19 May 2011 20:54:19 +0000
Subject: [issue12124] python -m test test_packaging test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <1305838459.77.0.468244700316.issue12124@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/issue12124>
_______________________________________

From report at bugs.python.org  Thu May 19 22:55:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 20:55:11 +0000
Subject: [issue12124] python -m test test_packaging test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <1305838511.11.0.861778038953.issue12124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

OMG! I understood why the bug was not seen before: "python -m test test_zipimport test_zipimport" succeed because test_zipimport REMOVES testAFakeZlib tests after the first run!

New patch to remove this ugly hack (it is no more needed with my patch anyway).

----------
Added file: http://bugs.python.org/file22034/zipimport_get_data-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12124>
_______________________________________

From report at bugs.python.org  Thu May 19 22:57:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2011 20:57:49 +0000
Subject: [issue12124] python -m test test_packaging test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <1305838669.33.0.737604126957.issue12124@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"test_zipimport REMOVES testAFakeZlib tests after the first run" hack was introduced by a commit supposed to "test zipimport a bit more" :-)

changeset:   36383:7b3d915b6e9d
branch:      legacy-trunk
user:        Neal Norwitz <nnorwitz at gmail.com>
date:        Mon Jan 23 07:52:13 2006 +0000
files:       Lib/test/test_zipimport.py
description:
Test zipimporter a bit more.  Also get working with -R :: option for finding ref leaks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12124>
_______________________________________

From report at bugs.python.org  Thu May 19 23:39:06 2011
From: report at bugs.python.org (Chad Austin)
Date: Thu, 19 May 2011 21:39:06 +0000
Subject: [issue1449496] Python should use 3GB Address Space on Windows
Message-ID: <1305841146.26.0.205917224686.issue1449496@psf.upfronthosting.co.za>


Chad Austin <chad at imvu.com> added the comment:

IMVU's downloadable client is built atop CPython.  80% of our users use 32-bit Windows and 20% use 64-bit Windows.  We do not intend to provide 64-bit builds of our application for many of the same reasons sketched out in http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx

Process address space is one of our key bottlenecks: limiting the amount of cache we can mmap in, various runtime heap reserves, etc.  For those 20% of users running 64-bit Windows, /LARGEADDRESSAWARE would give 32-bit Python access to 4 GB of address space, which would certainly help them.

The other reason not to use 64-bit binaries is that they consume significantly more memory and cache, especially because Python is so pointer-heavy.

In the meantime, we can use editbin /LARGEADDRESSAWARE to modify the shipped .exes.

----------
nosy: +Chad.Austin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1449496>
_______________________________________

From report at bugs.python.org  Fri May 20 00:05:51 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 19 May 2011 22:05:51 +0000
Subject: [issue4558] with_stdc89
In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za>
Message-ID: <1305842751.11.0.640221401672.issue4558@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Issue with inline was resolved by configure macro.

----------
Added file: http://bugs.python.org/file22035/python3-20110520-c89.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4558>
_______________________________________

From report at bugs.python.org  Fri May 20 00:07:23 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 19 May 2011 22:07:23 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1305842843.95.0.728503678021.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file22036/python-py3k-20110520-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Fri May 20 00:11:06 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 19 May 2011 22:11:06 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305843066.25.0.88932564466.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

...py3k-20110520...:  with updates of integrated recently distutil2 (require patch from #3754 with same time-stamp).

----------
Added file: http://bugs.python.org/file22037/python-py3k-20110520-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 00:22:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2011 22:22:54 +0000
Subject: [issue12124] python -m test test_packaging test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <E1QNBcL-0001ci-H4@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 52d9183b34f8 by Victor Stinner in branch '3.1':
Issue #12124: zipimport doesn't keep a reference to zlib.decompress() anymore
http://hg.python.org/cpython/rev/52d9183b34f8

New changeset a043d8e168b3 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12124: zipimport doesn't keep a reference to
http://hg.python.org/cpython/rev/a043d8e168b3

New changeset 9e13869b7639 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12124: zipimport doesn't keep a reference to
http://hg.python.org/cpython/rev/9e13869b7639

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12124>
_______________________________________

From report at bugs.python.org  Fri May 20 00:55:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 19 May 2011 22:55:48 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305845748.8.0.59311045889.issue12107@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello Christophe,

First and foremost, I think that the FD_CLOEXEC approach is terminally broken, as it should have been the default in Unix. Now, we're stuck with this bad design.
But we can't simply change the default to FD_CLOEXEC, for two reasons:
- we can't silently change the Unix semantics
- this is going to break some applications: for example, FD inherited across exec is used by super servers such as inetd, and there are others very legitimate uses

>  in the class TCPServer
>  add the following 2 lines in __init__ after self.socket = socket( ...:
>    flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
>    fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)

There are at least two problems with this approach:
1) there's a race between the socket creation and the call to fcntl
2) accept doesn't necessarily inherit the FD_CLOEXEC flag

1) can be fixed on systems that support it through SOCK_CLOEXEC
2) can be fixed on systems that support it through accept4(), but it seems to break badly on some systems, see issue #10115

But I think this is a perfectly legitimate request, so one approach to tackle this problem could be:
- since accept4() seems to fail so badly in some configurations, the only portable and reliable choice left is probably to call accept() then fcntl(FD_CLOEXEC) (there's a race, but it's better than nothing). We might reconsider this syscall in a couple years when we're sure it's implemented correctly
- in the socketserver module, add a new set_socket_cloexec attribute to BaseServer, which would do the right thing (i.e. create the socket with SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in TCPServer, call fcntl(FD_CLOEXEC) after accept.

That way, this would at least fix the problem for people using the socketserver module. People using sockets directly of course have the option of using SOCK_CLOEXEC and fcntl(FD_CLOEXEC) explicitely in their code.

Gregory, any thoughts on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Fri May 20 02:08:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:08:50 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It looks like a test of test_packaging removes some data from sysconfig._SCHEMES:

http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1239/steps/test/logs/stdio

======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/tests/test_command_build_ext.py", line 58, in test_build_ext
    cmd.ensure_finalized()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/command/cmd.py", line 104, in ensure_finalized
    self.finalize_options()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/packaging/command/build_ext.py", line 159, in finalize_options
    py_include = sysconfig.get_path('include')
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'include'

...



======================================================================
ERROR: test_get_path (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_sysconfig.py", line 110, in test_get_path
    res = get_path(name, scheme)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'confdir'

***

I fixed a cleanup function in Lib/packaging/tests/test_command_install_data.py: commit [6267a4645f5f]. Let see if it does fix the bug or not.

----------
components: Tests
messages: 136342
nosy: haypo, tarek
priority: normal
severity: normal
status: open
title: test_sysconfig fails on OpenIndiana because of test_packaging
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12125>
_______________________________________

From report at bugs.python.org  Fri May 20 02:10:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:10:52 +0000
Subject: [issue12118] test_imp failure
In-Reply-To: <1305821985.21.0.668805686693.issue12118@psf.upfronthosting.co.za>
Message-ID: <1305850252.01.0.536853415568.issue12118@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #12117.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12118>
_______________________________________

From report at bugs.python.org  Fri May 20 02:11:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:11:39 +0000
Subject: [issue12119] test_distutils failure
In-Reply-To: <1305822053.61.0.184404379566.issue12119@psf.upfronthosting.co.za>
Message-ID: <1305850299.56.0.594183650908.issue12119@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #12117.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12119>
_______________________________________

From report at bugs.python.org  Fri May 20 02:12:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:12:09 +0000
Subject: [issue12123] test_import failures
In-Reply-To: <1305822408.68.0.563434237022.issue12123@psf.upfronthosting.co.za>
Message-ID: <1305850329.87.0.922776195354.issue12123@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #12117.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12123>
_______________________________________

From report at bugs.python.org  Fri May 20 02:12:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:12:33 +0000
Subject: [issue12122] test_runpy failure
In-Reply-To: <1305822302.23.0.333065443048.issue12122@psf.upfronthosting.co.za>
Message-ID: <1305850353.2.0.240987881424.issue12122@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #12117.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12122>
_______________________________________

From report at bugs.python.org  Fri May 20 02:12:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:12:56 +0000
Subject: [issue12120] test_packaging failure
In-Reply-To: <1305822128.84.0.738916530306.issue12120@psf.upfronthosting.co.za>
Message-ID: <1305850376.42.0.4662556682.issue12120@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #12117.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12120>
_______________________________________

From report at bugs.python.org  Fri May 20 02:14:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:14:01 +0000
Subject: [issue12117] test_importlib failure
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305850441.27.0.778360422071.issue12117@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The following issues has been marked as a duplicate of this issue:
 - issue #12118 (test_imp)
 - issue #12119 (test_distutils)
 - issue #12120 (test_packaging)
 - issue #12122 (test_runpy)
 - issue #12123 (test_import)

Tarek did the following commit to try to fix test_packaging:

New changeset 9d1fb6a9104b by Tarek Ziade in branch 'default':
Issue #12120, Issue #12119: tests were missing a sys.dont_write_bytecode check
http://hg.python.org/cpython/rev/9d1fb6a9104b

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 02:16:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:16:27 +0000
Subject: [issue12117] test_importlib failure
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305850587.78.0.280687289849.issue12117@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Traceback of the duplicate issues:

======================================================================
ERROR: test_issue5604 (test.test_imp.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_imp.py", line 163, in test_issue5604
    temp_mod_name, imp.cache_from_source(temp_mod_name + '.py'))
IOError: [Errno 2] No such file or directory

======================================================================
FAIL: test_package_data (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/distutils/tests/test_build_py.py", line 61, in test_package_data
    self.assertTrue("__init__.pyc" in files)
AssertionError: False is not true

======================================================================
FAIL: test_package_data (packaging.tests.test_command_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/packaging/tests/test_command_build_py.py", line 64, in test_package_data
    self.assertIn("__init__.pyc", files)
AssertionError: '__init__.pyc' not found in ['README.txt', '__init__.py']


======================================================================
ERROR: test_explicit_relative_import (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 283, in test_explicit_relative_import
    self._check_relative_imports(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 257, in _check_relative_imports
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_main_relative_import (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 288, in test_main_relative_import
    self._check_relative_imports(depth, "__main__")
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 257, in _check_relative_imports
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_run_module (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 273, in test_run_module
    self._check_module(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 177, in _check_module
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_run_package (test.test_runpy.RunModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 278, in test_run_package
    self._check_package(depth)
  File "/home/antoine/t/cpython/Lib/test/test_runpy.py", line 201, in _check_package
    make_legacy_pyc(mod_fname)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory


======================================================================
ERROR: test_file_to_source (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 253, in test_file_to_source
    make_legacy_pyc(source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test___cached___legacy_pyc (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 584, in test___cached___legacy_pyc
    pyc_file = make_legacy_pyc(self.source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
ERROR: test_missing_source_legacy (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 564, in test_missing_source_legacy
    pyc_file = make_legacy_pyc(self.source)
  File "/home/antoine/t/cpython/Lib/test/support.py", line 217, in make_legacy_pyc
    os.rename(pyc_file, legacy_pyc)
OSError: [Errno 2] No such file or directory

======================================================================
FAIL: test_execute_bit_not_copied (test.test_import.ImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 112, in test_execute_bit_not_copied
    self.fail("__import__ did not result in creation of "
AssertionError: __import__ did not result in creation of either a .pyc or .pyo file

======================================================================
FAIL: test_import_pyc_path (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 531, in test_import_pyc_path
    self.assertTrue(os.path.exists('__pycache__'))
AssertionError: False is not true

======================================================================
FAIL: test_missing_source (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 552, in test_missing_source
    self.assertTrue(os.path.exists(pyc_file))
AssertionError: False is not true

======================================================================
FAIL: test_unwritable_directory (test.test_import.PycacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/test/test_import.py", line 543, in test_unwritable_directory
    self.assertTrue(os.path.exists('__pycache__'))
AssertionError: False is not true

---

Antoine's setup (msg136318):

"Indeed, PYTHONDONTWRITEBYTECODE seems set by default on this Linux install... Ouch."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 02:17:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:17:43 +0000
Subject: [issue12117] test_importlib failure
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305850663.95.0.608540638124.issue12117@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +alexis, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 02:18:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 00:18:43 +0000
Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib,
	test_imp, test_distutils, test_packaging, test_runpy, test_import
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305850723.94.0.422532923704.issue12117@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: test_importlib failure -> Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 02:23:52 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 20 May 2011 00:23:52 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

http://docs.python.org/py3k/howto/sockets.html#non-blocking-sockets

"And if you put a socket in more than one input list, it will only be (at most) in one output list."


>>> import socket
>>> s = socket.socket()
>>> s.connect(('localhost', 22))
>>> import select
>>> select.select([s], [s], [])
([<socket._socketobject object at 0xb764333c>], [<socket._socketobject object at 0xb764333c>], [])
>>>

----------
assignee: docs at python
components: Documentation
messages: 136350
nosy: docs at python, exarkun
priority: normal
severity: normal
status: open
title: incorrect select documentation
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Fri May 20 05:20:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 May 2011 03:20:08 +0000
Subject: [issue12104] os.path.join('/some/path',
	'') adds extra slash at end of result
In-Reply-To: <1305745526.57.0.545420875857.issue12104@psf.upfronthosting.co.za>
Message-ID: <1305861608.49.0.168496304911.issue12104@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also #9921.

----------
nosy: +r.david.murray
resolution: rejected -> duplicate
superseder:  -> os.path.join('x','') behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12104>
_______________________________________

From report at bugs.python.org  Fri May 20 06:19:44 2011
From: report at bugs.python.org (Peter Wentworth)
Date: Fri, 20 May 2011 04:19:44 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>


New submission from Peter Wentworth <p.wentworth at ict.ru.ac.za>:

In Python 3 we no longer have octal literals. The assignment
x = 0050  
gives an invalid token error.

But the assignment
y = int("0050") assigns the value 50 to y.

I would advocate consistency in the two situations, and prefer that leading zeros should be permitted on numbers.

----------
components: Interpreter Core
messages: 136352
nosy: Peter.Wentworth
priority: normal
severity: normal
status: open
title: Inconsistent leading zero treatment
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 06:55:48 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 20 May 2011 04:55:48 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305867348.57.0.473008930939.issue12105@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Why not to implement 'e' letter in py3k ?

In systems where O_CLOEXEC is not supported in open(), flag should be set non-atomically using fcntl.

To exclude races (in concurrent threads), this two ops should be done under lock (GIL?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Fri May 20 07:20:38 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 20 May 2011 05:20:38 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305868838.9.0.261712117764.issue12127@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

There's a good rationale against supporting leading zeros in integer literals in PEP 3127:

    http://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax

----------
nosy: +petri.lehtinen
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 07:40:33 2011
From: report at bugs.python.org (Greg Hellings)
Date: Fri, 20 May 2011 05:40:33 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1305870033.01.0.349451412087.issue3754@psf.upfronthosting.co.za>


Changes by Greg Hellings <greg.hellings at gmail.com>:


----------
nosy: +Greg.Hellings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Fri May 20 08:34:20 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 20 May 2011 06:34:20 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1305873260.15.0.274583982555.issue1054041@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/issue1054041>
_______________________________________

From report at bugs.python.org  Fri May 20 09:02:54 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 May 2011 07:02:54 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305874974.19.0.782372531566.issue12127@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
type: compile error -> feature request
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 09:08:41 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 May 2011 07:08:41 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305875321.37.0.248915265875.issue12127@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this is something that should be brought up for wider discussion on the python-dev mailing list.  It may be that people are ready to allow those leading zeros for Python 3.3 or 3.4.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 10:52:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 08:52:26 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305867348.57.0.473008930939.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305881540.16663.1.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Why not to implement 'e' letter in py3k ?
> 
> In systems where O_CLOEXEC is not supported in open(), flag should be set non-atomically using fcntl.

Having an atomic or non-atomic behaviour depending on the OS is not a
good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Fri May 20 10:57:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 May 2011 08:57:32 +0000
Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib,
	test_imp, test_distutils, test_packaging, test_runpy, test_import
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305881852.66.0.0230213675034.issue12117@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Several of these could be handled just by having test.support.make_legacy_pyc() fall back to compiling from source if sys.dont_write_bytecode is set.

The others may need to be skipped in that situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 11:16:32 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 20 May 2011 09:16:32 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305882992.43.0.580300827316.issue12127@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 11:18:11 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 09:18:11 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305883091.54.0.121840333537.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> To exclude races (in concurrent threads), this two ops should be done under lock (GIL?)

That won't work, because open(), like other slow syscalls, is called without the GIL held. Furthermore, it wouldn't be atomic anyway (imagine a fork is done from a C extension without the GIL held).
So we would end up tricking people into using a 'e' flag that, contrarily to GNU fopen(), would not be atomic.
Since the fopen() 'e' flag is only available on platform supporting O_CLOEXEC, you're exactly as portable using the fdopen() trick. And you're sure of what's happening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Fri May 20 11:33:26 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 20 May 2011 09:33:26 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1305884006.21.0.291248908515.issue12105@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/issue12105>
_______________________________________

From report at bugs.python.org  Fri May 20 12:02:10 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 20 May 2011 10:02:10 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1305885730.59.0.434766639079.issue1006238@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

hello wrobell , I see that issue3754 has patches for more recent line of code and issue 1597850 is related too.  Would you like to test the patches in there? If successful, this feature can be pushed further (and considered) for inclusion.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Fri May 20 12:06:56 2011
From: report at bugs.python.org (wrobell)
Date: Fri, 20 May 2011 10:06:56 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1305886016.52.0.421110808386.issue1006238@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

Senthil,

I would be more than happy to do that but for Python 3.2 (or there is no chance to backport it?). Python 3.3 is too far in time at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Fri May 20 12:08:16 2011
From: report at bugs.python.org (wrobell)
Date: Fri, 20 May 2011 10:08:16 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1305886096.28.0.899438909399.issue1597850@psf.upfronthosting.co.za>


Changes by wrobell <wrobell at pld-linux.org>:


----------
nosy: +wrobell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri May 20 12:08:25 2011
From: report at bugs.python.org (wrobell)
Date: Fri, 20 May 2011 10:08:25 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1305886105.02.0.900852007686.issue3754@psf.upfronthosting.co.za>


Changes by wrobell <wrobell at pld-linux.org>:


----------
nosy: +wrobell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Fri May 20 12:19:36 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 20 May 2011 10:19:36 +0000
Subject: [issue1006238] cross compile patch
In-Reply-To: <1305886016.52.0.421110808386.issue1006238@psf.upfronthosting.co.za>
Message-ID: <20110520101928.GA7025@kevin>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Code compatibility wise there is not much difference between Python3.2
and Python3.3. So you can do it for Python3.2 (in a bitbucket cpython
branch) and it is found stable, there are good chances that it will be
can be made in Python3.3 and future. I don't think, this would be
backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Fri May 20 12:28:23 2011
From: report at bugs.python.org (Torsten Landschoff)
Date: Fri, 20 May 2011 10:28:23 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1305887303.44.0.37890024271.issue10740@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

I updated the patch for upstream pysqlite2. Available at

http://code.google.com/p/pysqlite/issues/detail?id=24

Patch over there is for Python 2 (tested with our production Python 2.6).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Fri May 20 13:53:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 May 2011 11:53:23 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305892403.68.0.463685162518.issue12127@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you have any use case for x = 0050?
I don't any reason to adding leading 0s to a literal, but with int() the situation is different because you might get string with leading 0s from somewhere else.  Also note that the int() function is more flexible and there are other similar "inconsistencies":

>>> x = int('??')
>>> x
12
>>> x = ??
  File "<stdin>", line 1
    x = ??
             ^
SyntaxError: invalid character in identifier


I suggest closing this as "rejected".

----------
nosy: +ezio.melotti, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 14:05:47 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 20 May 2011 12:05:47 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305893147.11.0.27970074892.issue12127@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The behaviour of int() can be made consistent with the syntax for Python
integer literals by specifying a base of 0:

    >>> int("0050", 0)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: invalid literal for int() with base 0: '0050'

    >>> int("0o050", 0)
    40

    >>> int("0x050", 0)
    80

    >>> int("0b010", 0)
    2

As for changing the default behaviour, I think it would be a bad idea.
Having ``0050'' be an invalid token is perhaps jarring to people used to
C/C++/Java/etc., but at least attempts to use it fail loudly and
obviously. Having it be valid and yet mean something different could lead
to nasty surprises for the unsuspecting.

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 14:07:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2011 12:07:14 +0000
Subject: [issue12072] Missing parenthesis in c-api/buffer
	PyBuffer_FillContiguousStrides
In-Reply-To: <1305310307.77.0.353459071063.issue12072@psf.upfronthosting.co.za>
Message-ID: <E1QNOU4-0007uW-Q9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6a546bf5252f by Ezio Melotti in branch '2.7':
#12072: add missing parenthesis in the doc.  Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/6a546bf5252f

New changeset 68134a384c73 by Ezio Melotti in branch '3.1':
#12072: add missing parenthesis in the doc.  Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/68134a384c73

New changeset 68dd623f77f4 by Ezio Melotti in branch '3.2':
#12072: merge with 3.1.
http://hg.python.org/cpython/rev/68dd623f77f4

New changeset d6f899ae4ca0 by Ezio Melotti in branch 'default':
#12072: merge with 3.2.
http://hg.python.org/cpython/rev/d6f899ae4ca0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12072>
_______________________________________

From report at bugs.python.org  Fri May 20 14:07:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 May 2011 12:07:54 +0000
Subject: [issue12072] Missing parenthesis in c-api/buffer
	PyBuffer_FillContiguousStrides
In-Reply-To: <1305310307.77.0.353459071063.issue12072@psf.upfronthosting.co.za>
Message-ID: <1305893274.3.0.617864159971.issue12072@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12072>
_______________________________________

From report at bugs.python.org  Fri May 20 14:09:43 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 20 May 2011 12:09:43 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305893383.15.0.192491749407.issue12127@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, I'd personally like to see those leading zeros accepted at some point in Python's future, for the sake of cleanliness and consistency.  Not just consistency with int(), but also e.g. with float literals:

>>> 0050.
50.0
>>> 0050
  File "<stdin>", line 1
    0050
       ^
SyntaxError: invalid token

I'm just not sure whether we're at that point yet.

I don't find the PEP 3127 argument that we should protect people from subsequent confusion in other languages with 'leading zero implies octal' semantics at all convincing.

On the other hand, I do see the case for not having Python 3 silently behave differently from Python 2.

It seems worth a discussion, at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 14:19:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 May 2011 12:19:51 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305893991.93.0.590864503576.issue12127@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If the leading 0s are valid for floats (and complex) literals then int literals are indeed inconsistent.
If we want consistency with the other literals, it is probably better allowing them for ints, because removing them from float/complex is not backward compatible, but on the other hand it might be better to wait a few more versions to avoid surprises for people porting 2.x code to 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 14:31:44 2011
From: report at bugs.python.org (Christophe Devriese)
Date: Fri, 20 May 2011 12:31:44 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305845748.8.0.59311045889.issue12107@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=HuhMSX7bqXi8OjEC1Bfmq2=gV2A@mail.gmail.com>


Christophe Devriese <christophe.devriese at gmail.com> added the comment:

I realize this bugreport cannot fix 35 years of a bad design decision in
linux. That's not the intention (that's a gordian knot I *will* be keeping a
safe distance from). The intention is to create a saner default situation
for most python programs.

Christophe

2011/5/20 Charles-Fran??ois Natali <report at bugs.python.org>

>
> Charles-Fran??ois Natali <neologix at free.fr> added the comment:
>
> Hello Christophe,
>
> First and foremost, I think that the FD_CLOEXEC approach is terminally
> broken, as it should have been the default in Unix. Now, we're stuck with
> this bad design.
> But we can't simply change the default to FD_CLOEXEC, for two reasons:
> - we can't silently change the Unix semantics
> - this is going to break some applications: for example, FD inherited
> across exec is used by super servers such as inetd, and there are others
> very legitimate uses
>
> >  in the class TCPServer
> >  add the following 2 lines in __init__ after self.socket = socket( ...:
> >    flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
> >    fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)
>
> There are at least two problems with this approach:
> 1) there's a race between the socket creation and the call to fcntl
> 2) accept doesn't necessarily inherit the FD_CLOEXEC flag
>
> 1) can be fixed on systems that support it through SOCK_CLOEXEC
> 2) can be fixed on systems that support it through accept4(), but it seems
> to break badly on some systems, see issue #10115
>
> But I think this is a perfectly legitimate request, so one approach to
> tackle this problem could be:
> - since accept4() seems to fail so badly in some configurations, the only
> portable and reliable choice left is probably to call accept() then
> fcntl(FD_CLOEXEC) (there's a race, but it's better than nothing). We might
> reconsider this syscall in a couple years when we're sure it's implemented
> correctly
> - in the socketserver module, add a new set_socket_cloexec attribute to
> BaseServer, which would do the right thing (i.e. create the socket with
> SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in
> TCPServer, call fcntl(FD_CLOEXEC) after accept.
>
> That way, this would at least fix the problem for people using the
> socketserver module. People using sockets directly of course have the option
> of using SOCK_CLOEXEC and fcntl(FD_CLOEXEC) explicitely in their code.
>
> Gregory, any thoughts on this?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12107>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22038/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________
-------------- next part --------------
I realize this bugreport cannot fix 35 years of a bad design decision in linux. That&#39;s not the intention (that&#39;s a gordian knot I *will* be keeping a safe distance from). The intention is to create a saner default situation for most python programs.<div>

<br></div><div>Christophe<br><br><div class="gmail_quote">2011/5/20 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>
Hello Christophe,<br>
<br>
First and foremost, I think that the FD_CLOEXEC approach is terminally broken, as it should have been the default in Unix. Now, we&#39;re stuck with this bad design.<br>
But we can&#39;t simply change the default to FD_CLOEXEC, for two reasons:<br>
- we can&#39;t silently change the Unix semantics<br>
- this is going to break some applications: for example, FD inherited across exec is used by super servers such as inetd, and there are others very legitimate uses<br>
<div class="im"><br>
&gt; ??in the class TCPServer<br>
&gt; ??add the following 2 lines in __init__ after self.socket = socket( ...:<br>
&gt; ?? ??flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)<br>
&gt; ?? ??fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)<br>
<br>
</div>There are at least two problems with this approach:<br>
1) there&#39;s a race between the socket creation and the call to fcntl<br>
2) accept doesn&#39;t necessarily inherit the FD_CLOEXEC flag<br>
<br>
1) can be fixed on systems that support it through SOCK_CLOEXEC<br>
2) can be fixed on systems that support it through accept4(), but it seems to break badly on some systems, see issue #10115<br>
<br>
But I think this is a perfectly legitimate request, so one approach to tackle this problem could be:<br>
- since accept4() seems to fail so badly in some configurations, the only portable and reliable choice left is probably to call accept() then fcntl(FD_CLOEXEC) (there&#39;s a race, but it&#39;s better than nothing). We might reconsider this syscall in a couple years when we&#39;re sure it&#39;s implemented correctly<br>


- in the socketserver module, add a new set_socket_cloexec attribute to BaseServer, which would do the right thing (i.e. create the socket with SOCK_CLOEXEC if available, otherwise call fcntl(FD_CLOEXEC)), and in TCPServer, call fcntl(FD_CLOEXEC) after accept.<br>


<br>
That way, this would at least fix the problem for people using the socketserver module. People using sockets directly of course have the option of using SOCK_CLOEXEC and fcntl(FD_CLOEXEC) explicitely in their code.<br>
<br>
Gregory, any thoughts on this?<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue12107" target="_blank">http://bugs.python.org/issue12107</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Fri May 20 15:04:56 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 20 May 2011 13:04:56 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305896696.72.0.983981419958.issue12127@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't buy the "confusion with other languages" argument. It's a different language. People know that.

I'd like to see leading zeros allowed for integer literals, but I don't feel strongly about it, so +0. I'd mainly use them for tables of numbers that I'd like to line up.

If using 2to3 or 3to2, they could deal with it. The only case it would cause you problems is code that you want to run unchanged in 2.x and 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 15:15:28 2011
From: report at bugs.python.org (Greg Hellings)
Date: Fri, 20 May 2011 13:15:28 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1305897328.13.0.692768011722.issue3754@psf.upfronthosting.co.za>


Greg Hellings <greg.hellings at gmail.com> added the comment:

Current patch errors with the following message:
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -L/manual/lib -L/binary/lib -L/manual/lib -L/binary/lib  Parser/acceler.o Parser/grammar1.o Pars
er/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o
Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain
.o -lintl -lpthread  -o Parser/pgen.exe
./Grammar/Grammar ./Include/graminit.h ./Python/graminit.c
./Grammar/Grammar: line 18: single_input:: command not found
./Grammar/Grammar: line 18: simple_stmt: command not found
./Grammar/Grammar: line 18: compound_stmt: command not found
./Grammar/Grammar: line 19: syntax error near unexpected token `NEWLINE'
./Grammar/Grammar: line 19: `file_input: (NEWLINE | stmt)* ENDMARKER'
make: *** [Parser/pgen.stamp] Error 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Fri May 20 15:24:47 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 20 May 2011 13:24:47 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1305897887.21.0.294351469315.issue6727@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Per the suggestion in the Visual Studio forums, I posted a report against Visual Studio here: https://connect.microsoft.com/VisualStudio/feedback/details/669601/regression-calling-wstat64i32-on-symlink-directory-with-kb2467174-installed#details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Fri May 20 15:43:05 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 May 2011 13:43:05 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305898985.6.0.912423615894.issue12127@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

IMO 3.3 is definitely too soon.  3.4 may be too, depending on how many people are stuck on legacy systems using 2.7.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 16:01:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 14:01:15 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305900075.66.0.516940161192.issue1746656@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22025/socket_if.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 16:03:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 14:03:29 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305900209.69.0.897663837163.issue1746656@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> You use UTF-8 encoding:

Here's an updated patch taking your comments into account (I'm really blissfully ignorant when it comes to encoding issues, so I hope it will be OK this time).

----------
Added file: http://bugs.python.org/file22039/socket_if.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 16:19:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 14:19:49 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <BANLkTi=HuhMSX7bqXi8OjEC1Bfmq2=gV2A@mail.gmail.com>
Message-ID: <BANLkTinPnBKD936-q_PnBq86TCVvDqz49g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> That's not the intention (that's a gordian knot I *will* be keeping
> a
> safe distance from). The intention is to create a saner default situation
> for most python programs.

I understand what you're saying, and I agree with you on the principle.
But the point I was making is that we can't make this the "default
situation", for the reasons explained above (we can't change the
default socket semantics, and it's going to break some applications,
which is unacceptable).
That's why I was suggesting to add this as an option to the
socketserver module (since that's the piece of code you were referring
to).
The Python interpreter is not a simple standalone library/application,
we can't just make those kind of changes.

P.S.: please avoid sending html messages, they result in a spurious
"unnamed" file being attached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Fri May 20 16:22:07 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 May 2011 14:22:07 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305901327.65.7.92473100005e-05.issue1746656@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

that patch looks good.  though I do wish we had a function similar to PyObject_AsStringEncodedFSDefault() so that the ParseTuple call wasn't needed for this relatively common operation when interfacing with system library calls that deal in C strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 16:24:38 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 May 2011 14:24:38 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1305901478.7.0.301380478519.issue1597850@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy:  -gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Fri May 20 16:38:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2011 14:38:49 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
In-Reply-To: <1305901327.65.7.92473100005e-05.issue1746656@psf.upfronthosting.co.za>
Message-ID: <1305902323.6368.9.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> that patch looks good

I tested it with non-ASCII interface names: it works as expected with
ASCII and UTF-8 locales. It's the first time that I see the "O&" format
for Py_BuildValue(), I didn't know this one. The patch looks good.

@neologix: You can commit it into Python 3.3. Tell me if you need
help ;-)

> though I do wish we had a function similar to
> PyObject_AsStringEncodedFSDefault() so that the ParseTuple call wasn't
> needed for this relatively common operation when interfacing with
> system library calls that deal in C strings.

PyUnicode_FSConverter and PyUnicode_FSDecoder don't fit your needs?

What you would be the purpose of PyObject_AsStringEncodedFSDefault()?
What is its prototype?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 16:54:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2011 14:54:56 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <E1QNR6N-00061c-8d@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset cc60d0283fad by Charles-Fran?ois Natali in branch 'default':
Issue #1746656: make if_nameindex(), if_indextoname() and if_nametoindex()
http://hg.python.org/cpython/rev/cc60d0283fad

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 17:03:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:03:57 +0000
Subject: [issue11643] Use |version| instead of X.Y in the doc
In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za>
Message-ID: <1305903837.11.0.52307606313.issue11643@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11643>
_______________________________________

From report at bugs.python.org  Fri May 20 17:04:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 May 2011 15:04:46 +0000
Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib,
	test_imp, test_distutils, test_packaging, test_runpy, test_import
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305903886.43.0.190700339728.issue12117@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Honestly, now that it's been established that it has to do with a bogus system default (on Mageia/Mandriva installs), I'm not sure it's worth fixing if it means adding more logic to the tests.

----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 17:06:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:06:44 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1305904004.85.0.50284627316.issue1006238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi wrobell.  As a new feature, this could not be backported to stable versions.  Regarding status, there are currently a number of duplicate or overlapping reports and patches, it?s rather difficult to find out which one should be reviewed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Fri May 20 17:07:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 May 2011 15:07:12 +0000
Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib,
	test_imp, test_distutils, test_packaging, test_runpy, test_import
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305904032.5.0.854624356081.issue12117@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In fact, not fixing it might send a small message as to what we think about that particular system default :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 17:11:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:11:52 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904312.41.0.0706223534088.issue3871@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> ...py3k-20110520...
For successive versions of the same patch, it?s best to remove the obsolete ones and add the new one, all with the same name.

> with updates of integrated recently distutil2
Your patch touches distutils, which is not acceptable.  Also, it contains a lot of FIXME comments.  I suggest you open reports for those bugs and make this one depend on them.  Please post a patch when it?s ready for review; in-development patches don?t really help.

----------
dependencies: +cross-compilation support for python build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:11:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:11:59 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904319.21.0.717034645425.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17362/python-trunk-20100516-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:02 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904322.93.0.775532426257.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file17779/python-trunk-20100626-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:08 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904328.02.0.0494656005219.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18626/python-trunk-20100824-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:11 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904331.0.0.465330813096.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19587/python-2.7-20101112-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:13 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904333.76.0.0166035400648.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19589/python-py3k-20101112-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:17 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904337.01.0.00349285555939.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20538/python-2.7-20110126-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:20 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904340.07.0.799696585472.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20540/python-py3k-20110126-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:22 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904342.98.0.23142304709.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file21571/python-py3k-20110407-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:12:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 May 2011 15:12:54 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1305904374.72.0.980355541623.issue3871@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18339/py3k_mingwmsys_autogen.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri May 20 17:18:49 2011
From: report at bugs.python.org (wrobell)
Date: Fri, 20 May 2011 15:18:49 +0000
Subject: [issue1006238] cross compile patch
Message-ID: <1305904729.97.0.435341911023.issue1006238@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

Hi Eric,

Good point. I was just about ask, which bug and patch are the primary ones? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1006238>
_______________________________________

From report at bugs.python.org  Fri May 20 17:18:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 15:18:51 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
In-Reply-To: <1305902323.6368.9.camel@marge>
Message-ID: <BANLkTi=7WK39E7t+OP2SOkML=hK-9W-vvg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> @neologix: You can commit it into Python 3.3. Tell me if you need
> help ;-)

My first commit :-)
What's the next step?
Can this issue be closed, or should I wait until the tests pass on
some buildbot?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 17:20:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 May 2011 15:20:41 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
In-Reply-To: <BANLkTi=7WK39E7t+OP2SOkML=hK-9W-vvg@mail.gmail.com>
Message-ID: <1305904838.3579.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My first commit :-)
> What's the next step?
> Can this issue be closed, or should I wait until the tests pass on
> some buildbot?

You can close the issue nevertheless (as "fixed" /
"committed/rejected"). It can be reopened later if there's a buildbot
failure.
(note that many 3.x buildbots are currently red for another reason :))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 17:27:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 15:27:38 +0000
Subject: [issue1746656] IPv6 Interface naming/indexing functions
Message-ID: <1305905258.76.0.395650461198.issue1746656@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/issue1746656>
_______________________________________

From report at bugs.python.org  Fri May 20 18:15:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 16:15:45 +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: <1305908145.76.0.635044528327.issue8035@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file16758/urllib_redirect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Fri May 20 18:18:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 May 2011 16:18:40 +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: <1305908320.28.0.631059841675.issue8035@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Those URLs don't trigger the problem anymore, but AFAICT from the code, this problem is still present in py3k.
Here's an updated patch.

----------
Added file: http://bugs.python.org/file22040/urllib_redirect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8035>
_______________________________________

From report at bugs.python.org  Fri May 20 18:54:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 May 2011 16:54:06 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305910446.78.0.430673051397.issue12098@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patches.
One comment: I'm not sure a frozen interpreter can take regular Python flags.
As for the test, you could run a function returning sys.flags from the child to the parent, and check that the returned value is equal to the parent's sys.flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Fri May 20 19:15:03 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 20 May 2011 17:15:03 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

When you create an `abc.abstractproperty` on a class, any subclass must override it as an actual property in order to be instantiable. But sometimes you want to override it with a data attribute instead, i.e. `self.x = 5` instead of `x = property(...)`. It would be nice if doing `self.x = 5` would satisfy `abc.abstractproperty` and allow the subclass to be instantiable.

----------
components: Library (Lib)
messages: 136388
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Allow `abc.abstractproperty` to be overridden by a data attribute
type: feature request
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 19:18:35 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 20 May 2011 17:18:35 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305911915.22.0.2954191287.issue12128@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

SGTM.  I've written code where this would have been useful.

Could you write a patch?

----------
nosy: +stutzbach
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 20:26:02 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 20 May 2011 18:26:02 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1305915962.24.0.763971732014.issue12127@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

-0 on making it valid ever, due to the different meaning in many other languages.

-1 on making it valid while many still use a version of python where it's valid with a different meaning.  Maybe for Python 4. ;-)

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Fri May 20 20:40:55 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 May 2011 18:40:55 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305916855.12.0.459301693827.issue12128@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Wow!  I was literally working on this problem yesterday.  The abstract check is done at instantiation time (in object.__new__, typeobject.c).  So as it stands __new__ has no way to validate that all your abstract properties have been implemented unless they are actual properties.

The solution I found simplest is to not inherit from an ABC but rather to register your class to it, and make sure that you are compliant, whether through properties or instance names.

If there is a way to check the instance for names that "implement" abstract properties that would be a useful thing in my mind.  However, I am not sure this is doable without some serious work.  Yesterday I put together a list of some solutions that would mostly work that I plan on sending to python-list today.  I am not sure if baking that into the core of Python will work.

In my mind this is a question of if abstract methods (and thereby properties) are a promise that an instance complies with an interface or just that the class of the instance complies.

----------
nosy: +ericsnow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 20:42:27 2011
From: report at bugs.python.org (Justin)
Date: Fri, 20 May 2011 18:42:27 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1305916947.09.0.57322741518.issue11109@psf.upfronthosting.co.za>


Justin <justin.warkentin at gmail.com> added the comment:

Don't mean to nag. Just checking to see if anyone has taken it upon themselves to commit this yet since it's been a couple more months :P

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Fri May 20 20:48:27 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 20 May 2011 18:48:27 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305917307.54.0.431024989834.issue12128@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

I misread the original request.  I'm +1 on making the following work, if it doesn't work already:

class MySubClass(MyAbstractClass):
    SOME_LIMIT = 5  # Implements abstract property with fixed value

We should be able to check that at instance creation time.

I think abstract methods and properties are to force the class to define methods/properties.  I don't think we should be checking if the instance adds things that are not defined at the class level (i.e., don't try to detect "self.SOME_LIMT = 5").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 21:00:13 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 20 May 2011 19:00:13 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305918013.01.0.618991533281.issue12128@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Daniel, the behavior you describe is already present in Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 21:02:46 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 20 May 2011 19:02:46 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305918166.11.0.162722858083.issue12128@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> Daniel, the behavior you describe is already present in Python 3.2.

Awesome. :)

Do you have a compelling use-case for making "self.x = 5" satisfy an abstractproperty requirement?  One of the problems with that approach is that the instance does not satisfy the requirements until the line in __init__ is called that sets self.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 21:04:04 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 20 May 2011 19:04:04 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305918244.55.0.0293000501848.issue12128@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Eric, do you think that a solution can be made by calling `__init__` inside of `ABCMeta.__new__` and then afterwards checking the instance for attributes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 21:07:59 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 20 May 2011 19:07:59 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305918479.88.0.30860276695.issue12128@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Ah, I got confused, there's no way we can call `__init__` in `ABCMeta.__new__`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 21:23:45 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 May 2011 19:23:45 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305919425.67.0.95458498638.issue12128@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

As far as I have found, there isn't a way to make it work implicitly without changing object.__new__.  I just posted some of the approaches I could think of to python-list: 

http://mail.python.org/pipermail/python-list/2011-May/1272604.html

Mostly it is a matter of using decorators for validation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 21:52:42 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 20 May 2011 19:52:42 +0000
Subject: [issue11455] issue a warning when populating a CPython type dict with
	non-string keys
In-Reply-To: <1299704028.56.0.168922481621.issue11455@psf.upfronthosting.co.za>
Message-ID: <1305921162.25.0.787468214609.issue11455@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/issue11455>
_______________________________________

From report at bugs.python.org  Fri May 20 22:18:34 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Fri, 20 May 2011 20:18:34 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305922714.9.0.334328702966.issue12098@psf.upfronthosting.co.za>


Changes by Sergey Mezentsev <thebits at yandex.ru>:


Removed file: http://bugs.python.org/file22021/Issue12098.branch-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Fri May 20 22:18:37 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Fri, 20 May 2011 20:18:37 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305922717.34.0.890962872673.issue12098@psf.upfronthosting.co.za>


Changes by Sergey Mezentsev <thebits at yandex.ru>:


Removed file: http://bugs.python.org/file22022/Issue12098.branch-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Fri May 20 22:18:58 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Fri, 20 May 2011 20:18:58 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305922738.53.0.311700803629.issue12098@psf.upfronthosting.co.za>


Changes by Sergey Mezentsev <thebits at yandex.ru>:


Added file: http://bugs.python.org/file22041/Issue12098.branch-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Fri May 20 22:19:07 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Fri, 20 May 2011 20:19:07 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305922747.67.0.87755171362.issue12098@psf.upfronthosting.co.za>


Changes by Sergey Mezentsev <thebits at yandex.ru>:


Added file: http://bugs.python.org/file22042/Issue12098.branch-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Fri May 20 22:23:25 2011
From: report at bugs.python.org (Sergey Mezentsev)
Date: Fri, 20 May 2011 20:23:25 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1305923005.72.0.0172561326466.issue12098@psf.upfronthosting.co.za>


Sergey Mezentsev <thebits at yandex.ru> added the comment:

I updated the patch.
Added a test and remove arguments for frozen interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Fri May 20 22:23:50 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 20 May 2011 20:23:50 +0000
Subject: [issue11442] list_directory() in SimpleHTTPServer.py should add
	charset=... to Content-type header
In-Reply-To: <1299611115.64.0.389023379939.issue11442@psf.upfronthosting.co.za>
Message-ID: <1305923030.53.0.867996890989.issue11442@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Senthil, I just want to verify.  You applied this patch to the Python 2.6 branch in hg, but not in svn, correct?  Since I'm going to be making the 2.6.7 release from svn, I am porting this patch over to the svn 2.6 branch.  You don't have to do that, but if you can just confirm it, that would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11442>
_______________________________________

From report at bugs.python.org  Fri May 20 22:27:44 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 20 May 2011 20:27:44 +0000
Subject: [issue12128] Allow `abc.abstractproperty` to be overridden by a data
	attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1305923264.38.0.180768217344.issue12128@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/issue12128>
_______________________________________

From report at bugs.python.org  Fri May 20 22:52:14 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 20 May 2011 20:52:14 +0000
Subject: [issue11662] Redirect vulnerability in urllib/urllib2
In-Reply-To: <1300979217.98.0.998462672739.issue11662@psf.upfronthosting.co.za>
Message-ID: <1305924734.66.0.267521933215.issue11662@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I think this is another patch that needs to be cross-ported to the 2.6 svn branch (which I'll do).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11662>
_______________________________________

From report at bugs.python.org  Fri May 20 23:00:18 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 20 May 2011 21:00:18 +0000
Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib,
	test_imp, test_distutils, test_packaging, test_runpy, test_import
In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za>
Message-ID: <1305925218.41.0.822298660764.issue12117@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/issue12117>
_______________________________________

From report at bugs.python.org  Fri May 20 23:14:03 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 20 May 2011 21:14:03 +0000
Subject: [issue10808] ssl unwrap fails with Error 0
In-Reply-To: <1293997937.94.0.348375754935.issue10808@psf.upfronthosting.co.za>
Message-ID: <1305926043.13.0.377861869889.issue10808@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/issue10808>
_______________________________________

From report at bugs.python.org  Sat May 21 00:02:11 2011
From: report at bugs.python.org (Kyle Keating)
Date: Fri, 20 May 2011 22:02:11 +0000
Subject: [issue12129] Document Object Model API - validation
In-Reply-To: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>
Message-ID: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>


New submission from Kyle Keating <kkeating at gmail.com>:

I was doing some tests on using this library and I noticed xml elements and attribute names could be created with mal-formed xml because special characters which can break validation are not cleaned or converted from their literal forms. Only the attribute values are cleaned, but not the names.

For example

import xml.dom

...
doc.createElement("p></p>") 
...

will just embed a pair of p tags in the xml result. I thought that the xml spec did not permit <, >, &, \n etc. in the element name or attribute name? Could I get some clarification on this, thanks!

----------
components: Library (Lib)
messages: 136402
nosy: Kyle.Keating
priority: normal
severity: normal
status: open
title: Document Object Model API - validation
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12129>
_______________________________________

From report at bugs.python.org  Sat May 21 00:07:33 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 May 2011 22:07:33 +0000
Subject: [issue11442] list_directory() in SimpleHTTPServer.py should add
	charset=... to Content-type header
In-Reply-To: <1299611115.64.0.389023379939.issue11442@psf.upfronthosting.co.za>
Message-ID: <1305929253.93.0.872686109322.issue11442@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Let me confirm that. Since it is a security patch the entire point of it is to be placed in the release.

I don't want to question the reasons for doing the release from svn instead of from hg, but I do want to emphasize that the hg branch ought to be considered the master which svn should track as closely as possible.  The only reason to not port a patch to the svn branch would be if it was submitted to the hg branch in contradiction with some policy (e.g. a non-security fix to a branch that should only receive security fixes), and then it should probably be rolled back in the hg branch (and the decision to do so should be very visible on python-dev).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11442>
_______________________________________

From report at bugs.python.org  Sat May 21 00:37:04 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 20 May 2011 22:37:04 +0000
Subject: [issue11442] list_directory() in SimpleHTTPServer.py should add
	charset=... to Content-type header
In-Reply-To: <1305929253.93.0.872686109322.issue11442@psf.upfronthosting.co.za>
Message-ID: <20110520183657.4d30068a@neurotica.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On May 20, 2011, at 10:07 PM, Guido van Rossum wrote:

>
>Guido van Rossum <guido at python.org> added the comment:
>
>Let me confirm that. Since it is a security patch the entire point of it is
>to be placed in the release.

Cool, I've ported it over to svn.

>I don't want to question the reasons for doing the release from svn instead
>of from hg, but I do want to emphasize that the hg branch ought to be
>considered the master which svn should track as closely as possible.  The
>only reason to not port a patch to the svn branch would be if it was
>submitted to the hg branch in contradiction with some policy (e.g. a
>non-security fix to a branch that should only receive security fixes), and
>then it should probably be rolled back in the hg branch (and the decision to
>do so should be very visible on python-dev).

I'm okay with that.  Right now I can't push my reconciled hg repo though
because line ending changes were committed to various files in hg but not
svn.  I don't think they're appropriate frankly, but rolling them back causes
hg push to fail.

Antoine suggested whitelisting those files in .hgeol, which I'll investigate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11442>
_______________________________________

From report at bugs.python.org  Sat May 21 00:47:52 2011
From: report at bugs.python.org (Julian)
Date: Fri, 20 May 2011 22:47:52 +0000
Subject: [issue12130] regex 0.1.20110514 findall overlapped not working with
	'start of string' expression
In-Reply-To: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>
Message-ID: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>


New submission from Julian <jcerruti at gmail.com>:

Trying to use regex 0.1.2011051 with the overlapped=True feature

It works great, unless I have the 'start of string' (caret) character in my regular expression:


>>> regex.findall(r"a.*b","abadalaba",overlapped=True)
['abadalab', 'adalab', 'alab', 'ab']
>>> regex.findall(r"^a.*b","abadalaba",overlapped=True)
['abadalab']

----------
components: Regular Expressions
messages: 136405
nosy: jcerruti
priority: normal
severity: normal
status: open
title: regex 0.1.20110514 findall overlapped not working with 'start of string' expression
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12130>
_______________________________________

From report at bugs.python.org  Sat May 21 00:49:10 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 20 May 2011 22:49:10 +0000
Subject: [issue12130] regex 0.1.20110514 findall overlapped not working with
	'start of string' expression
In-Reply-To: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>
Message-ID: <1305931750.56.0.93035965456.issue12130@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Please report this to the regex bug tracker.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12130>
_______________________________________

From report at bugs.python.org  Sat May 21 00:51:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 May 2011 22:51:22 +0000
Subject: [issue12130] regex 0.1.20110514 findall overlapped not working with
	'start of string' expression
In-Reply-To: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>
Message-ID: <1305931882.48.0.0552608750615.issue12130@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think that's normal, the ^ matches only at the beginning of the string.

----------
nosy: +ezio.melotti, mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12130>
_______________________________________

From report at bugs.python.org  Sat May 21 00:53:05 2011
From: report at bugs.python.org (Julian)
Date: Fri, 20 May 2011 22:53:05 +0000
Subject: [issue12130] regex 0.1.20110514 findall overlapped not working with
	'start of string' expression
In-Reply-To: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>
Message-ID: <1305931985.03.0.281278290765.issue12130@psf.upfronthosting.co.za>


Julian <jcerruti at gmail.com> added the comment:

Sorry for posting in the wrong tracker. I'm a bit dumb: can you please point me to the right tracker?

I know ^ should match the beginning of the string, but there are multiple overlapping matches with the beginning of the string (as the first set of results show). Maybe I'm missing something subtler here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12130>
_______________________________________

From report at bugs.python.org  Sat May 21 01:03:07 2011
From: report at bugs.python.org (Julian)
Date: Fri, 20 May 2011 23:03:07 +0000
Subject: [issue12130] regex 0.1.20110514 findall overlapped not working with
	'start of string' expression
In-Reply-To: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>
Message-ID: <1305932587.48.0.924811137675.issue12130@psf.upfronthosting.co.za>


Julian <jcerruti at gmail.com> added the comment:

Just in case somebody else stumbles upon this, I ended up posting here: https://code.google.com/p/mrab-regex-hg/issues/detail?id=10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12130>
_______________________________________

From report at bugs.python.org  Sat May 21 01:24:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 May 2011 23:24:52 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305933892.06.0.103642254028.issue12107@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file22038/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Sat May 21 01:32:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 May 2011 23:32:08 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305934328.92.0.534516907511.issue12126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The socket HOWTO looks so stupid, obscure and badly written that it should IMO be deleted.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sat May 21 01:33:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 May 2011 23:33:42 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305934422.96.0.721637121136.issue12126@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/issue12126>
_______________________________________

From report at bugs.python.org  Sat May 21 01:50:35 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 20 May 2011 23:50:35 +0000
Subject: [issue12024] 2.6 svn and hg branches are out of sync
In-Reply-To: <1304724015.49.0.713905819899.issue12024@psf.upfronthosting.co.za>
Message-ID: <1305935435.1.0.425301054717.issue12024@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Although hg2.6 is not yet pushed, svn2.6 has been sync'd so this is ready to go for 2.6.7rc2.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12024>
_______________________________________

From report at bugs.python.org  Sat May 21 02:13:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 May 2011 00:13:33 +0000
Subject: [issue12124] python -m test test_packaging test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <E1QNZow-0001Q2-Tm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bfceb8c8178a by Victor Stinner in branch '2.7':
Issue #12124: zipimport doesn't keep a reference to zlib.decompress() anymore
http://hg.python.org/cpython/rev/bfceb8c8178a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12124>
_______________________________________

From report at bugs.python.org  Sat May 21 02:13:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 May 2011 00:13:53 +0000
Subject: [issue12124] python -m test test_packaging test_zipimport failure
In-Reply-To: <1305837725.55.0.659554087396.issue12124@psf.upfronthosting.co.za>
Message-ID: <1305936833.89.0.823141845801.issue12124@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/issue12124>
_______________________________________

From report at bugs.python.org  Sat May 21 02:15:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 May 2011 00:15:05 +0000
Subject: [issue4558] with_stdc89
In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za>
Message-ID: <1305936905.3.0.347490223506.issue4558@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Is it still useful to ensure that ISO C89 compilers are supported in 2011?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4558>
_______________________________________

From report at bugs.python.org  Sat May 21 02:22:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 May 2011 00:22:05 +0000
Subject: [issue12114] packaging.util._find_exe_version(): potential deadlock
In-Reply-To: <1305810302.14.0.0379253224029.issue12114@psf.upfronthosting.co.za>
Message-ID: <E1QNZxD-0001wU-HD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bf5b974e7d32 by Victor Stinner in branch 'default':
Close #12114: fix a potential deadlock in packaging.util._find_exe_version()
http://hg.python.org/cpython/rev/bf5b974e7d32

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12114>
_______________________________________

From report at bugs.python.org  Sat May 21 02:22:55 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 21 May 2011 00:22:55 +0000
Subject: [issue12130] regex 0.1.20110514 findall overlapped not working with
	'start of string' expression
In-Reply-To: <1305931672.68.0.439399541624.issue12130@psf.upfronthosting.co.za>
Message-ID: <1305937375.12.0.679937265866.issue12130@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Replied to the regex bug tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12130>
_______________________________________

From report at bugs.python.org  Sat May 21 02:31:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 May 2011 00:31:57 +0000
Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT
Message-ID: <1305937917.15.0.0287151961931.issue1054041@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+        kill(getpid(), SIGINT);

kill() doesn't exist on Windows: use raise() which is more portable and doesn't require a PID argument.

We may need to do something on Windows for console applications: see SetConsoleCtrlHandler(),
http://msdn.microsoft.com/en-us/library/ms686016(v=vs.85).aspx

+        self.assertEqual(returncode, -signal.SIGINT,
+                         "not a SIGINT exit code. process stderr:\n%s" % stderr)

I don't think that such test can pass on Windows.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054041>
_______________________________________

From report at bugs.python.org  Sat May 21 02:33:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 May 2011 00:33:46 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1305938026.03.0.486366892725.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that issue #12100 should be fixed (wontfix/fixed) before this one.

----------
dependencies: +Incremental encoders of CJK codecs reset the codec at each call to encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Sat May 21 03:01:57 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 21 May 2011 01:01:57 +0000
Subject: [issue11702] dir on return value of msilib.OpenDatabase() crashes
	python
In-Reply-To: <1301325222.81.0.910767875041.issue11702@psf.upfronthosting.co.za>
Message-ID: <1305939717.11.0.535332588646.issue11702@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

I wasn't so happy trawling through \windows\installer either :) 

Creating an MSI to test is very simple, and actually quicker than I had originally thought. The latest patch (support_dir_for_msi_objs.patch) creates the one and just uses that. Optionally I could create a new one each time setUp()/tearDown(). But was thinking - let's do that if/when we need to :)

The latest patch updates the tests - but no change to the C code.

(I doubt the error you received is a bug in msilib, and I couldn't repro even by opening EVERY MSI in my windows\installer dir. It could be a rights/security issue? The previous test was not opening as READ ONLY - even though it never saved the db, so that may be another reason?)

----------
Added file: http://bugs.python.org/file22043/support_dir_for_msi_objs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11702>
_______________________________________

From report at bugs.python.org  Sat May 21 05:14:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 May 2011 03:14:11 +0000
Subject: [issue12131] python built with --prefix fails in site.py with no
	section 'posix_prefix'
In-Reply-To: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>
Message-ID: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

[reported by Stefan Behnel]

With the "packaging" changes introducing Lib/sysconfig.cfg and corresponding changes to Lib/sysconfig.py to depend on them, builds that use --prefix= to install outside of the build directory fail during startup when site.py calls sysconfig:

Traceback (most recent call last):
   File "/.../python/lib/python3.3/configparser.py", line 842, in items
     d.update(self._sections[section])
KeyError: 'posix_prefix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "/.../python/lib/python3.3/site.py", line 537, in <module>
     main()
   File "/.../python/lib/python3.3/site.py", line 522, in main
     known_paths = addusersitepackages(known_paths)
   File "/.../python/lib/python3.3/site.py", line 263, in addusersitepackages
     user_site = getusersitepackages()
   File "/.../python/lib/python3.3/site.py", line 238, in getusersitepackages
     user_base = getuserbase() # this will also set USER_BASE
   File "/.../python/lib/python3.3/site.py", line 228, in getuserbase
     USER_BASE = get_config_var('userbase')
   File "/.../python/lib/python3.3/sysconfig.py", line 576, in get_config_var
     return get_config_vars().get(name)
   File "/.../python/lib/python3.3/sysconfig.py", line 472, in get_config_vars
     _init_posix(_CONFIG_VARS)
   File "/.../python/lib/python3.3/sysconfig.py", line 324, in _init_posix
     makefile = get_makefile_filename()
   File "/.../python/lib/python3.3/sysconfig.py", line 318, in 
get_makefile_filename
     return os.path.join(get_path('stdlib'), config_dir_name, 'Makefile')
   File "/.../python/lib/python3.3/sysconfig.py", line 436, in get_path
     return get_paths(scheme, vars, expand)[name]
   File "/.../python/lib/python3.3/sysconfig.py", line 426, in get_paths
     return _expand_vars(scheme, vars)
   File "/.../python/lib/python3.3/sysconfig.py", line 142, in _expand_vars
     for key, value in _SCHEMES.items(scheme):
   File "/.../python/lib/python3.3/configparser.py", line 845, in items
     raise NoSectionError(section)
configparser.NoSectionError: No section: 'posix_prefix'

The problem is that sysconfig.py expects sysconfig.cfg to be in the same directory as it but no changes were added to the Makefile to do so.

A simple-minded workaround is something like this:

diff --git a/Makefile.pre.in b/Makefile.pre.in
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -947,7 +947,7 @@
                else    true; \
                fi; \
        done
-       @for i in $(srcdir)/Lib/*.py $(srcdir)/Lib/*.egg-info ; \
+       @for i in $(srcdir)/Lib/*.py $(srcdir)/Lib/*.egg-info $(srcdir)/Lib/*.cfg ; \
        do \
                if test -x $$i; then \
                        $(INSTALL_SCRIPT) $$i $(DESTDIR)$(LIBDEST); \

I am not sure if that is a proper long-term fix.  For real Python installations, say, via a binary installer, is the lib/python3.x directory the proper place for a .cfg file?  Is it expected that site admins will modify this file?

----------
assignee: tarek
messages: 136419
nosy: ned.deily, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: python built with --prefix fails in site.py with no section 'posix_prefix'
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12131>
_______________________________________

From report at bugs.python.org  Sat May 21 06:52:01 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 21 May 2011 04:52:01 +0000
Subject: [issue12131] python built with --prefix fails in site.py with no
	section 'posix_prefix'
In-Reply-To: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>
Message-ID: <1305953521.56.0.959980267044.issue12131@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12131>
_______________________________________

From report at bugs.python.org  Sat May 21 08:14:59 2011
From: report at bugs.python.org (lekma)
Date: Sat, 21 May 2011 06:14:59 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1305958499.73.0.620784125199.issue10271@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

how should we go about that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Sat May 21 08:46:03 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 May 2011 06:46:03 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305960363.68.0.950528147858.issue12126@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Antoine, can you be more specific? I recall finding it quite useful when first learning Python. Perhaps it can be improved in a few specific places, but overall I don't think it's a bad document.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sat May 21 09:22:37 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 May 2011 07:22:37 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305962557.4.0.524843733797.issue12126@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

This issue Jean-Paul raises seems to be a plain error. select() certainly can return that some given socket is both readable and writable (this is explicitly discussed in Steven's APitUE $14.5), and I see no evidence in the implementation of Python's selectmodule.c that it somehow violates the output of system's select() to behave otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sat May 21 09:23:56 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 May 2011 07:23:56 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1305962636.92.0.145851370456.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Can this issue be closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Sat May 21 10:09:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 May 2011 08:09:23 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1305965363.61.0.956884462979.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  Sat May 21 11:28:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 May 2011 09:28:43 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1305970123.24.0.168591274517.issue12090@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Georg, I think this might be a release blocker. I hope it is
not too late for 3.2.1.


Victor, was there any reason that 79fcd71d0356 wasn't backported?
Otherwise I'll go ahead and push it to 3.2.

----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Sat May 21 11:29:43 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 May 2011 09:29:43 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1305970183.56.0.0635965816456.issue2091@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

In Python 3, the documentation no longer mentions that 'U' should not work with '+' (or 'w' or 'a', for that matter), and the code throws ValueError if 'U' is used with 'w' or 'a', but not '+'.

On the other hand, the documentation *does* mention that 'U' is for backwards compatibility and shouldn't be used with new code.

In light of this, how do you suggest to proceed with this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
_______________________________________

From report at bugs.python.org  Sat May 21 12:12:40 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 May 2011 10:12:40 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1305972760.26.0.61785399458.issue12003@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I think that if this note should stay in the docs at all, it should be as concise as possible, so I like Terry's -1+2*(step<0) option. I also tested it on a few more inputs and it works fine.

If there are no objections, I can commit it to python 2.7 docs in a couple of days.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Sat May 21 12:17:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 21 May 2011 10:17:19 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1305973039.56.0.922484909623.issue1441530@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's actually an obvious case of heap fragmentation due to long-lived chunks being realloc()ed to a smaller size. Some malloc implementations can choke on this (e.g. OS-X's malloc is known to not shrink blocks when realloc() is called with a smaller size).
The solution is simply to use a StringIO to avoid holding references to those blocks for too long.
Patch attached.

----------
Added file: http://bugs.python.org/file22044/imaplib_read.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sat May 21 12:17:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 21 May 2011 10:17:38 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1305973058.27.0.760952834741.issue1441530@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file16747/imaplib_read.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sat May 21 12:26:49 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 21 May 2011 10:26:49 +0000
Subject: [issue12131] python built with --prefix fails in site.py with no
	section 'posix_prefix'
In-Reply-To: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>
Message-ID: <1305973609.8.0.237102207347.issue12131@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/issue12131>
_______________________________________

From report at bugs.python.org  Sat May 21 12:42:51 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 21 May 2011 10:42:51 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

test_packaging fails when regrtest is run with the -j option (run multiple tests concurrently).


    $ ./python -Wd -E -bb -j0 -v test_packaging

    [snip]

    ======================================================================
    ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_compiler_option (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_ext_fullpath (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_finalize_options (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_get_outputs (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_get_source_files (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_optional_extension (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_solaris_enable_shared (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'

    ======================================================================
    ERROR: test_user_site (packaging.tests.test_command_build_ext.BuildExtTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/nadeem/code/src/cpython/python/Lib/packaging/tests/test_command_build_ext.py", line 34, in setUp
        shutil.copy(_get_source_filename(), self.tmp_dir)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 133, in copy
        copyfile(src, dst)
      File "/home/nadeem/code/src/cpython/python/Lib/shutil.py", line 98, in copyfile
        with open(src, 'rb') as fsrc:
    IOError: [Errno 2] No such file or directory: '/home/nadeem/code/src/cpython/python/build/test_python_17565/Modules/xxmodule.c'


It seems that these tests assume they are running under the top-level
directory of the checkout (which is not the case when -j is used).

----------
components: Tests
messages: 136428
nosy: nadeem.vawda, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging failures when run with -j
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sat May 21 13:01:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 11:01:27 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305975687.75.0.779081458321.issue12126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, my main issue with this document is that it doesn't seem to have a well-defined destination:
- people who know sockets won't learn anything from it
- but people who don't know sockets will probably find it clear as mud (for example, what's an "INET" or "STREAM" socket? what's "select"?)

I have other issues, such as the style/tone it's written in. I'm sure the author had fun writing it but it doesn't fit well with the rest of the documentation. Also, the author gives a lot of "advice" without really giving an example ("if somewhere in those input lists of sockets is one which has died a nasty death, the select will fail" -> is that really true? what is a "nasty death" and how is that supposed to happen? couldn't the author have put a 3-line example to demonstrate this supposed drawback and how it manifests?).

And, finally, many statements seem arbitrary ("There?s no question that the fastest sockets code uses non-blocking sockets and select to multiplex them") or plain wrong ("threading support in Unixes varies both in API and quality. So the normal Unix solution is to fork a subprocess to deal with each connection"). I don't think giving misleading advice to users is really a good idea. And suggesting beginners they use non-blocking sockets without even *showing* how (or pointing to asyncore or Twisted) is a very bad idea. select() is not enough, you still have to be prepared to get EAGAIN or EWOULDBLOCK when calling recv() or send() (i.e. select() can give false positives).

Oh and I think it's obsolete too, because the "class mysocket" concatenates the output of recv() with a str rather than a bytes object. Not to mention that features of the "class mysocket" can be had using a buffered socket.makefile() instead of writing custom code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sat May 21 13:11:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 21 May 2011 11:11:44 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1305976304.06.0.0730772252186.issue5715@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks for reporting this, the current behaviour is clearly wrong. The child process doesn't need to - and shouldn't - inherit the server socket.
The custom idiom when writting such code is to close the new socket (well, in TCP) in the parent process, and close the server socket in the child process.
That's what the attached patch does.
Since I really doubt anyone using socketserver ever used the server's socket from the handler, this shouldn't be a problem for existing code (and the server's socket was never documented to be usable from the request handler).

----------
keywords: +needs review, patch
nosy: +charles-francois.natali, haypo
stage: test needed -> patch review
Added file: http://bugs.python.org/file22045/ss_fork_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Sat May 21 13:15:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 11:15:41 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1305976541.37.0.967493411965.issue12132@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
components: +Distutils2
nosy: +alexis, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sat May 21 14:22:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 21 May 2011 12:22:58 +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: <20110521122242.GA34134@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -810,6 +810,35 @@
    Availability: Unix, and Windows.

+.. function:: fullfsync(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.
+
+   This non-standart function is *optionally* made available to access such
+   special functionality when feasible.  It will force write of file buffers to
+   disk and the flush of disk caches of the file given by file descriptor *fd*.
+   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, 'fullfsync'):
+         os.fullfsync(f.fileno())
+      elif hasattr(os, 'fsync'):
+         os.fsync(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: Unix.
+
+
 .. 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
@@ -835,12 +835,12 @@

 class TestInvalidFD(unittest.TestCase):
     singles = ["fchdir", "dup", "fdopen", "fdatasync", "fstat",
-               "fstatvfs", "fsync", "tcgetpgrp", "ttyname"]
+               "fstatvfs", "fsync", "fullfsync", "tcgetpgrp", "ttyname"]
     #singles.append("close")
-    #We omit close because it doesn'r raise an exception on some platforms
+    # We omit close because it doesn't raise an exception on some platforms
     def get_single(f):
         def helper(self):
-            if  hasattr(os, f):
+            if hasattr(os, f):
                 self.check(getattr(os, f))
         return helper
     for f in singles:
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -174,6 +174,11 @@
 #endif /* ! __IBMC__ */

 #ifndef _MSC_VER
+  /* os.fullfsync()? */
+# if (defined HAVE_FSYNC && ((defined __APPLE__ && defined F_FULLFSYNC) || \
+                             (defined __NetBSD__ && defined FDISKSYNC)))
+#  define PROVIDE_FULLFSYNC
+# endif

 #if defined(__sgi)&&_COMPILER_VERSION>=700
 /* declare ctermid_r if compiling with MIPSPro 7.x in ANSI C mode
@@ -2129,6 +2134,41 @@
 {
     return posix_fildes(fdobj, fsync);
 }
+
+# ifdef PROVIDE_FULLFSYNC
+PyDoc_STRVAR(fullfsync__doc__,
+"fullfsync(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 *
+fullfsync(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 */
+    res = fcntl(fd, F_FULLFSYNC);
+    if (res < 0 && errno == ENOTTY)
+        res = fsync(fd);
+#  elif defined __NetBSD__
+    res = fsync_range(fd, FFILESYNC | FDISKSYNC, 0, 0);
+#  endif
+    Py_END_ALLOW_THREADS
+
+    if (res < 0)
+        return posix_error();
+    Py_INCREF(Py_None);
+    return Py_None;
+}
+# endif /* PROVIDE_FULLFSYNC */
 #endif /* HAVE_FSYNC */

 #ifdef HAVE_SYNC
@@ -9473,6 +9513,9 @@
 #endif
 #ifdef HAVE_FSYNC
     {"fsync",       posix_fsync, METH_O, posix_fsync__doc__},
+# ifdef PROVIDE_FULLFSYNC
+    {"fullfsync",   fullfsync, METH_O, fullfsync__doc__},
+# endif
 #endif
 #ifdef HAVE_SYNC
     {"sync",        posix_sync, METH_NOARGS, posix_sync__doc__},

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat May 21 14:36:14 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 21 May 2011 12:36:14 +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: <1305981374.0.0.145958918648.issue11877@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(This was an attachment to an empty mail message.)

----------
Added file: http://bugs.python.org/file22046/11877-standalone.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________

From report at bugs.python.org  Sat May 21 14:42:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 May 2011 12:42:36 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

In case of error (e.g. timeout error), urllib.request leaves the socket open:

import urllib.request as ur
import socket
s = socket.socket()
s.bind(('localhost', 10000))
s.listen(0)
socket.setdefaulttimeout(5)
ur.urlopen('http://localhost.localdomain:10000')

outputs:

sys:1: ResourceWarning: unclosed <socket.socket object, fd=4, family=2, type=1, proto=6>

Traceback (most recent call last):
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1146, in do_open
    r = h.getresponse()  # an HTTPResponse instance
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 1046, in getresponse
    response.begin()
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 346, in begin
    version, status, reason = self._read_status()
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 308, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/home/wolf/dev/py/py3k/Lib/socket.py", line 279, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 369, in open
    response = self._open(req, data)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 387, in _open
    '_open', req)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 347, in _call_chain
    result = func(*args)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1163, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1148, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error timed out>
>>>

AFAIU, when urlopen returns or raises, the socket can be closed, so the attached patch adds a "finally" that calls close() on the HTTPConnection object.  The test suite pass (except for a mock that was missing the close method), but I'm not 100% sure that it's always safe to call close().

This ResourceWarning has been exposed by test_packaging.

----------
components: Library (Lib)
files: issue12133.diff
keywords: needs review, patch
messages: 136433
nosy: davide.rizzo, ezio.melotti, jhylton, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: ResourceWarning in urllib.request
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file22047/issue12133.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Sat May 21 14:43:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 21 May 2011 12:43:32 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <20110521124323.GA53399@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Looked at it again and i think it's much better english with an
additional ..to ensure "that" local...
@Ross, aren't you a native english speaker?  What do you say?

----------
Added file: http://bugs.python.org/file22048/12102.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/mmap.rst b/Doc/library/mmap.rst
--- a/Doc/library/mmap.rst
+++ b/Doc/library/mmap.rst
@@ -21,6 +21,11 @@
 :func:`os.open` function, which returns a file descriptor directly (the file
 still needs to be closed when done).
 
+..note::
+   If you want to create a memory-mapping for a writable, buffered file, you
+   should :func:`flush` the file first.  This is necessary to ensure that local
+   modifications to the buffers are actually available to the mapping.
+
 For both the Unix and Windows versions of the constructor, *access* may be
 specified as an optional keyword parameter. *access* accepts one of three
 values: :const:`ACCESS_READ`, :const:`ACCESS_WRITE`, or :const:`ACCESS_COPY`

From report at bugs.python.org  Sat May 21 14:48:43 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 21 May 2011 12:48:43 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1305982123.42.0.572440177628.issue12133@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/issue12133>
_______________________________________

From report at bugs.python.org  Sat May 21 14:59:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 May 2011 12:59:04 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1305982744.62.0.145800504942.issue11015@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

There are still functions that are not documented, so I think this should stay open until we documented them (unless they shouldn't be documented -- in that case it can be closed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Sat May 21 15:05:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 21 May 2011 13:05:55 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1305983155.07.0.104188949138.issue12133@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Ezio, the connection can be closed via the finally call as you do in the patch. There are times when request object is re-used, but before the connection is made. It may also help to understand how the code in the packaging was invoking it.

If you run the whole suite and see the nothing breaks (to ensure that something is not waiting for the socket and trying to close later), go ahead with the patch.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Sat May 21 15:16:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 May 2011 13:16:33 +0000
Subject: [issue12133] ResourceWarning in urllib.request
In-Reply-To: <1305981756.26.0.970199835965.issue12133@psf.upfronthosting.co.za>
Message-ID: <1305983793.96.0.405389006282.issue12133@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The packaging test (test_pypi_simple.py:test_uses_mirrors) creates a server and a mirror, starts the mirror only, tries to connect to the server, and then falls back on the mirror when the server raises a timeout error.
The code in the first message does more or less the same, causing a timeout error and the resource warning.

I haven't checked in detail the urllib tests, but the fact that there are no ResourceWarnings while running test_urllib might mean that this case isn't currently tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12133>
_______________________________________

From report at bugs.python.org  Sat May 21 15:33:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 21 May 2011 13:33:12 +0000
Subject: [issue4558] with_stdc89
In-Reply-To: <1228530326.9.0.419197104424.issue4558@psf.upfronthosting.co.za>
Message-ID: <1305984792.32.0.0730032708292.issue4558@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, vs2008 requires that variables must be declared at the start of a block, and IIRC there is a AIX compiler that does not allow // comments.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4558>
_______________________________________

From report at bugs.python.org  Sat May 21 15:38:06 2011
From: report at bugs.python.org (poq)
Date: Sat, 21 May 2011 13:38:06 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>


New submission from poq <poq at gmx.com>:

import json, timeit
obj = [[1,2,3]*10]*10
class writable(object):
	def write(self, buf): pass
w = writable()
print('dumps: %.3f' % timeit.timeit(lambda: json.dumps(obj), number=10000))
print('dump:  %.3f' % timeit.timeit(lambda: json.dump(obj,w), number=10000))

On my machine this outputs:
dumps: 0.391
dump:  4.501

I believe this is mostly caused by dump using JSONEncoder.iterencode without _one_shot=True, resulting in c_make_encoder not being used.

----------
components: Extension Modules
messages: 136439
nosy: poq
priority: normal
severity: normal
status: open
title: json.dump much slower than dumps
type: performance
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sat May 21 15:39:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 May 2011 13:39:19 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1305985159.48.0.88693563487.issue12134@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib) -Extension Modules
nosy: +ezio.melotti
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sat May 21 15:57:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 13:57:27 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1305986247.17.0.544389895162.issue12134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is indeed the case. And the solution is obvious: call dumps() and then write() the result yourself. If dump() used _one_shot=True, it would defeat the purpose of minimizing memory consumption by not buffering the whole result.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sat May 21 16:26:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 14:26:03 +0000
Subject: [issue12135] test_packaging failure under Windows
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Also, *please* provide stderr in the error message when an external command fails. Otherwise, it's impossible to properly debug failure of external commands.


======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\compiler\msvc9compiler.py", line 622, in link
    self.spawn([self.linker] + ld_args)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\compiler\ccompiler.py", line 847, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\util.py", line 783, in spawn
    raise PackagingExecError(msg % (cmd, exit_status))
packaging.errors.PackagingExecError: command '['C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\BIN\\link.exe', '/DLL', '/nologo', '/INCREMENTAL:no', '/DEBUG', '/pdb:None', '/LIBPATH:D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\libs', '/LIBPATH:D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\PCbuild', '/EXPORT:initxx', 'c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\Debug\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xxmodule.obj', '/OUT:c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xx_d.pyd', '/IMPLIB:c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\Debug\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xx_d.lib', '/MANIFESTFILE:c:\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\Debug\\docume~1\\db3l\\locals~1\\temp\\tmp3sylqy\\tmp4kk72e\\xx_d.pyd.manifest']' failed with exit status 1120

----------
assignee: tarek
components: Distutils2, Windows
messages: 136441
nosy: alexis, eric.araujo, pitrou, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: test_packaging failure under Windows
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12135>
_______________________________________

From report at bugs.python.org  Sat May 21 16:27:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 14:27:22 +0000
Subject: [issue12135] test_packaging failure under Windows
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1305988042.14.0.975993475538.issue12135@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Many other failures in http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4630/steps/test/logs/stdio , by the way

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12135>
_______________________________________

From report at bugs.python.org  Sat May 21 16:27:54 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 21 May 2011 14:27:54 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1305988074.93.0.831418736641.issue8898@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

The attached patch adds aliases for latin_N in encodings.aliases, and fixes email.charset behaviour according to codecs.lookup, as requested.
Tested on (Arch) Linux.

Am I supposed to add any unittest? I'm wavering about where they should be placed (in encodings or email?).

----------
keywords: +patch
nosy: +ezio.melotti, maker
Added file: http://bugs.python.org/file22049/issue8898.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sat May 21 16:34:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 14:34:28 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1305988468.71.0.622154101486.issue12012@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Victor, you broke the Solaris gcc buildbot on 2.7.
http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%202.7/builds/837

----------
assignee:  -> haypo
stage: patch review -> committed/rejected
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Sat May 21 16:35:33 2011
From: report at bugs.python.org (Christophe Devriese)
Date: Sat, 21 May 2011 14:35:33 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305933892.11.0.730865118331.issue12107@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=-A5JcEoRXsyEAi1fUo9tmm--_kA@mail.gmail.com>


Christophe Devriese <christophe.devriese at gmail.com> added the comment:

It would already be a nice piece of progress if you could request the
SO_CLOEXEC (with fallback to FD_CLOEXEC), say, in the constructor, or even
with a module variable. I hope at least this change can make it in, so that
we have a decent in-python solution that can be used from within, say,
django.

Christophe

On Sat, May 21, 2011 at 1:24 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Changes by Antoine Pitrou <pitrou at free.fr>:
>
>
> Removed file: http://bugs.python.org/file22038/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12107>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22050/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________
-------------- next part --------------
It would already be a nice piece of progress if you could request the SO_CLOEXEC (with fallback to FD_CLOEXEC), say, in the constructor, or even with a module variable. I hope at least this change can make it in, so that we have a decent in-python solution that can be used from within, say, django.<div>

<br></div><div>Christophe</div><div><br><div class="gmail_quote">On Sat, May 21, 2011 at 1:24 AM, Antoine Pitrou <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>
Changes by Antoine Pitrou &lt;<a href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt;:<br>
<br>
<br>
</div>Removed file: <a href="http://bugs.python.org/file22038/unnamed" target="_blank">http://bugs.python.org/file22038/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/issue12107" target="_blank">http://bugs.python.org/issue12107</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Sat May 21 16:43:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 14:43:17 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305988997.71.0.686018067459.issue12107@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The request is reasonable, but the best bet is for someone interested to provide a patch. See http://docs.python.org/devguide/ if you aren't acquainted with the development process.

----------
components: +Library (Lib)
nosy: +pitrou
stage:  -> needs patch
type: security -> feature request
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Sat May 21 16:43:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 14:43:28 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305989008.66.0.521575630233.issue12107@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file22050/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Sat May 21 16:50:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 21 May 2011 14:50:27 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1305989427.99.0.785757675893.issue12107@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

$ cat test_sock.py 
import socket
import fcntl


with socket.socket(socket.AF_INET, socket.SOCK_STREAM|socket.SOCK_CLOEXEC) as s:
    print(bool(fcntl.fcntl(s, fcntl.F_GETFD) & fcntl.FD_CLOEXEC))

$ ./python test_sock.py 
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Sat May 21 16:59:48 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 May 2011 14:59:48 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305989988.04.0.917088482418.issue12126@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

It makes sense to bring this up for discussion on pydev, then. Perhaps it will be decided to remove this document from the official documentation, possibly relegating it to the Wiki.

In the meantime, is there an objection to removing the incorrect statement Jean-Paul mentioned from the doc? It's obviously incorrect both in theory and practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sat May 21 17:07:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 15:07:50 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305989988.04.0.917088482418.issue12126@psf.upfronthosting.co.za>
Message-ID: <1305990465.31647.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It makes sense to bring this up for discussion on pydev, then.

Ok, done.

> In the meantime, is there an objection to removing the incorrect
> statement Jean-Paul mentioned from the doc?

Well, no.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sat May 21 17:28:12 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 May 2011 15:28:12 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <1305991692.59.0.77861116493.issue12090@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, it's not too late -- rc2 is shifted to next weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Sat May 21 17:31:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 15:31:10 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1305991870.24.0.498705748909.issue1441530@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch looks ok. Is 3.x also affected? The I/O stack changed quite a bit in 3.x.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sat May 21 17:35:48 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 21 May 2011 15:35:48 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1305992148.26.0.0168399800699.issue12102@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> Looked at it again and i think it's much better english with an
> additional ..to ensure "that" local...
> @Ross, aren't you a native english speaker?  What do you say?

Yes I am, but that doesn't make me any good ;-)

I'd probably agree that it's better with "that" included.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Sat May 21 17:41:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 15:41:08 +0000
Subject: [issue12136] test_logging fails when no ssl available
In-Reply-To: <1305992468.22.0.0355418363055.issue12136@psf.upfronthosting.co.za>
Message-ID: <1305992468.22.0.0355418363055.issue12136@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

======================================================================
ERROR: test_output (test.test_logging.HTTPHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_logging.py", line 1529, in test_output
    import ssl
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/importlib/_bootstrap.py", line 437, in load_module
    return self._load_module(fullname)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/importlib/_bootstrap.py", line 141, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/importlib/_bootstrap.py", line 342, in _load_module
    exec(code_object, module.__dict__)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/ssl.py", line 60, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: No module named '_ssl'

----------
assignee: vinay.sajip
components: Library (Lib), Tests
messages: 136453
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging fails when no ssl available
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12136>
_______________________________________

From report at bugs.python.org  Sat May 21 17:46:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 May 2011 15:46:49 +0000
Subject: [issue12136] test_logging fails when no ssl available
In-Reply-To: <1305992468.22.0.0355418363055.issue12136@psf.upfronthosting.co.za>
Message-ID: <E1QNoO8-0004Rw-84@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2be3ffa82293 by Vinay Sajip in branch 'default':
Issue #12136: Added change to handle non-availability of the ssl module.
http://hg.python.org/cpython/rev/2be3ffa82293

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12136>
_______________________________________

From report at bugs.python.org  Sat May 21 18:25:17 2011
From: report at bugs.python.org (Tres Seaver)
Date: Sat, 21 May 2011 16:25:17 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1305995117.97.0.355687424733.issue2091@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
nosy:  -tseaver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
_______________________________________

From report at bugs.python.org  Sat May 21 18:34:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 16:34:14 +0000
Subject: [issue12137] EBADF in test_urllibnet
In-Reply-To: <1305995654.0.0.162674044436.issue12137@psf.upfronthosting.co.za>
Message-ID: <1305995654.0.0.162674044436.issue12137@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is probably a transient failure due to the remote host being unavailable, but the "bad file descriptor" error is not ok:


test test_urllibnet failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_urllibnet.py", line 70, in test_readlines
    self.assertIsInstance(open_url.readlines(), list,
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/http/client.py", line 509, in read
    s = self.fp.read(amt)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/socket.py", line 279, in readinto
    return self._sock.recv_into(b)
socket.error: [Errno 9] Bad file descriptor

----------
components: Library (Lib)
messages: 136455
nosy: orsenthil, pitrou
priority: normal
severity: normal
status: open
title: EBADF in test_urllibnet
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12137>
_______________________________________

From report at bugs.python.org  Sat May 21 18:36:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 16:36:53 +0000
Subject: [issue12138] buggy use of transient_internet() in test_urllibnet
In-Reply-To: <1305995813.93.0.90503071832.issue12138@psf.upfronthosting.co.za>
Message-ID: <1305995813.93.0.90503071832.issue12138@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The code I added in b65f417dd266 is buggy, because it calls __exit__ with (None, None, None) rather than the exception to be tested.

----------
assignee: pitrou
components: Tests
messages: 136456
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: buggy use of transient_internet() in test_urllibnet
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12138>
_______________________________________

From report at bugs.python.org  Sat May 21 18:47:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 21 May 2011 16:47:57 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
In-Reply-To: <1305991870.24.0.498705748909.issue1441530@psf.upfronthosting.co.za>
Message-ID: <BANLkTik218XCYTh1qHoq+J=fF2NYnXeDwA@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> Patch looks ok. Is 3.x also affected? The I/O stack changed quite a bit in
> 3.x.

I think it's not affected, but I can't reproduce this behaviour with
glibc/eglibc, so don't just take my word for it.
The reason is that in py3k, imaplib uses a buffered reader to read
from the socket (obtained through sock.makefile()), and IIUC, reading
from a buffered reader n bytes will always return n bytes (unless EOF
is encountered or the underlying object is set to non-blocking),
contrarily to reading directly from a socket. So the resizing is done
from the buffered io module, which only grows the result buffer,
freeing the buffers returned by socket's recv() one at a time.

Note that if I'm right, another way to solve this would be to wrap the
SSL socket with a call to makefile, like what's already done for the
non-SSL case (and in py3k). This would also lead to cleaner and
simpler code, because we wouldn't need to handle partial reads
ourself.
That's what the patch attached does.
Note that if I'm correct, then the current py3k imaplib read() method
could also be simplified:

    def read(self, size):
        """Read 'size' bytes from remote."""
        chunks = []
        read = 0
        while read < size:
            data = self.file.read(min(size-read, 4096))
            if not data:
                break
            read += len(data)
            chunks.append(data)
        return b''.join(chunks)

It would also be a bit faster.
But since I can't reproduce this issue, I'd rather make sure it's
correct before making a such change.

----------
Added file: http://bugs.python.org/file22051/imaplib_ssl_makefile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________
-------------- next part --------------
diff -r b3f410dbab25 Lib/imaplib.py
--- a/Lib/imaplib.py	Fri May 20 11:49:06 2011 -0500
+++ b/Lib/imaplib.py	Sat May 21 18:24:01 2011 +0200
@@ -1158,28 +1158,17 @@
             self.port = port
             self.sock = socket.create_connection((host, port))
             self.sslobj = ssl.wrap_socket(self.sock, self.keyfile, self.certfile)
+            self.file = self.sslobj.makefile('rb')
 
 
         def read(self, size):
             """Read 'size' bytes from remote."""
-            # sslobj.read() sometimes returns < size bytes
-            chunks = []
-            read = 0
-            while read < size:
-                data = self.sslobj.read(min(size-read, 16384))
-                read += len(data)
-                chunks.append(data)
-
-            return ''.join(chunks)
+            return self.file.read(n)
 
 
         def readline(self):
             """Read line from remote."""
-            line = []
-            while 1:
-                char = self.sslobj.read(1)
-                line.append(char)
-                if char in ("\n", ""): return ''.join(line)
+            return self.file.readline()
 
 
         def send(self, data):

From report at bugs.python.org  Sat May 21 19:16:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 21 May 2011 17:16:33 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1305998193.64.0.970995127796.issue1441530@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

In the buffered reader case, the result buffer is actually pre-allocated with the total size, making fragmentation even less likely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sat May 21 20:09:00 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 21 May 2011 18:09:00 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

In FTPS, CCC command can be used to switch back to a clear-text control connection.
This can be useful to take advantage of firewalls that know how to handle NAT with non-secure FTP without opening fixed ports.
Patch in attachment includes lib, test and doc changes.

----------
assignee: giampaolo.rodola
files: ftplib-ccc.patch
keywords: patch
messages: 136459
nosy: giampaolo.rodola
priority: normal
severity: normal
stage: patch review
status: open
title: Add CCC command support to ftplib
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22052/ftplib-ccc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Sat May 21 20:13:04 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 18:13:04 +0000
Subject: [issue12135] test_packaging failure under Windows
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1306001584.18.0.301403988496.issue12135@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

As I said on python-dev, I am aware of the failures. I have fixed most of them today and yesterday. I have four left including this one.

So no need to add more issues, I am on it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12135>
_______________________________________

From report at bugs.python.org  Sat May 21 20:15:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 18:15:56 +0000
Subject: [issue12135] test_packaging failure under Windows
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1306001756.41.0.468208122425.issue12135@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Specifically, the "spawn" function *must* be fixed to include stderr in the exception message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12135>
_______________________________________

From report at bugs.python.org  Sat May 21 20:19:16 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 18:19:16 +0000
Subject: [issue12135] The spawn function should return stderr.
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1306001956.34.0.598520796098.issue12135@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

That's a feature request then, so we will see this once the bbot are green

----------
priority: critical -> normal
title: test_packaging failure under Windows -> The spawn function should return stderr.
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12135>
_______________________________________

From report at bugs.python.org  Sat May 21 20:19:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 18:19:45 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1306001985.39.0.488874687294.issue12139@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This can be useful to take advantage of firewalls that know how to
> handle NAT with non-secure FTP without opening fixed ports.

Can you explain this a little more?

+            resp = self.voidcmd('CCC')
+            self.sock = self.sock.unwrap()
+            return resp

Should the response be checked before calling unwrap()?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Sat May 21 20:22:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 18:22:27 +0000
Subject: [issue12135] The spawn function should return stderr.
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1306002147.8.0.883327900354.issue12135@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Same request for distutils in issue11599, by the way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12135>
_______________________________________

From report at bugs.python.org  Sat May 21 21:08:17 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 21 May 2011 19:08:17 +0000
Subject: [issue12139] Add CCC command support to ftplib
In-Reply-To: <1306001340.71.0.345746598563.issue12139@psf.upfronthosting.co.za>
Message-ID: <1306004897.28.0.355788486498.issue12139@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

voidcmd() expects a response code starting with "2" and automatically raises an exception otherwise.
A server succesfully accepting the CCC command is supposed to first reply with 220 and then shutdown() the SSL layer.
Client is supposed to do the same: first receive the 2xx response and then make the shutdown().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12139>
_______________________________________

From report at bugs.python.org  Sat May 21 21:18:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 19:18:08 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1306005488.04.0.890149510076.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Table 5.2 referenced above lists 10 operations, four of which (>, <,
> >=, and <=) are given spellings that are identical to the spellings of
> Python comparison operators.

Yep, those are included amongst the "various ad-hoc and traditional names and symbols".  So what?  It's still the case that IEEE 754 gives no requirement (or even recommendation) for how either of 'compareQuietLess' or 'compareSignalingLess' should be spelt in any particular language.

IOW, it's fine to argue that *you* personally would like Python's '<' to be bound to IEEE 754's 'compareSignalingLess' instead of the current effective binding to 'compareQuietLess', but it would be a bit disingenuous to claim that IEEE 754 recommends or requires that.  It doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 21 21:22:15 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 19:22:15 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1306005735.82.0.432039664378.issue11986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Prof. Kahan states that nan < x must signal.

Would that be the sentence that starts "In the syntax of C ..." ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Sat May 21 21:32:27 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 19:32:27 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1306006347.99.0.00190259995193.issue11986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> keep naive implementation of builtin max()

Agreed.

> provide symmetric float.max such that nan.max(x) = x.max(nan) = x (nan
> result would be a valid but less useful alternative.)

That might be viable (a math module function might also make sense here), though it feels a bit YAGNI to me.  If we were going to add such a method, it should follow IEEE 754:  nan.max(x) == x.max(n) == x, but also nan.min(x) == x.min(nan) == x, for finite x.  (See section 5.3.1.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Sat May 21 21:36:07 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 May 2011 19:36:07 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1306005488.04.0.890149510076.issue11949@psf.upfronthosting.co.za>
Message-ID: <BANLkTinPm=q=OkFyta_S-6ObS4-bqzWDBA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 21, 2011 at 3:18 PM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
>> Table 5.2 referenced above lists 10 operations, four of which (>, <,
>> >=, and <=) are given spellings that are identical to the spellings of
>> Python comparison operators.
>
> Yep, those are included amongst the "various ad-hoc and traditional names and symbols". ?So what?
> ?It's still the case that IEEE 754 gives no requirement (or even recommendation) for how either of
> 'compareQuietLess' or 'compareSignalingLess' should be spelt in any particular language.

IEEE 754 is not a standard that is directly applicable to the design
of programming languages.  For example, it is completely silent on the
issue of which operations should be implemented as infix operators and
which as functions.  Still, to the extent it is appropriate for IEEE
754 to say so, I think it says that '<' is 'compareSignalingLess'.

IEEE 754 can only be a guide for language design and not a
specification.  However, the decimal module, which was explicitly
designed for IEEE 754 compliance, makes order comparison operators
signaling.  What is the reason to make them quiet for floats other
than backward compatibility?  Note that backward compatibility is
likely not to be an issue if we make nan comparisons generate a
warning (possibly even off by default) rather than error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 21 21:44:29 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 May 2011 19:44:29 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1306005735.82.0.432039664378.issue11986@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=wemnpZ6pE4gR64KKhXhWV-Vg4PA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 21, 2011 at 3:22 PM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
>> Prof. Kahan states that nan < x must signal.
>
> Would that be the sentence that starts "In the syntax of C ..." ?

This is just sophistry.   If Python was more popular than C at the
time Prof. Kahan wrote this, he would write "in the syntax of Python."

(Not directly on-topic, but Python 3 seems to be moving towards C
spelling of operators.  I, for one, miss the removal of easy to type
'<>' in favor of finger-twisting '!='.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Sat May 21 21:48:17 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 19:48:17 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1306007297.85.0.406017777319.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> What is the reason to make them quiet for floats other
> than backward compatibility?

For me, none.  I'll happily agree that, all other things being equal, it's more natural (and more consistent with other languages) to have < correspond to the signaling operation, and in a new language that's probably what I'd go for.  But as a *change* to existing behaviour in a language that's been widely adopted for numerical work, the risk of breakage seems to me to outweigh any benefits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 21 21:49:12 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 21 May 2011 19:49:12 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306007352.1.0.943533874054.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sat May 21 21:50:48 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 19:50:48 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1306007448.52.0.148624714861.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

On the idea of a warning, I don't really see the point;  I find it hard to imagine it's really going to catch many real errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 21 21:54:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 19:54:46 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1306007686.88.0.798605392715.issue11986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> This is just sophistry.   If Python was more popular than C at the
> time Prof. Kahan wrote this, he would write "in the syntax of Python."

I doubt it.  C has a standard that explicitly states that < must signal on comparison with NaNs.  Python doesn't.

Alexander, I've read both these documents (Kahan's lecture notes and IEEE 754-2008) many many times.  I've looked hard in the past for language that would give this exact connection, about < signalling.  It just isn't there in either document, and it's dishonest to claim it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Sat May 21 21:58:03 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 May 2011 19:58:03 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1306007448.52.0.148624714861.issue11949@psf.upfronthosting.co.za>
Message-ID: <BANLkTima8LB175Ztonn1PR3kKPjj1MjLvw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 21, 2011 at 3:50 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> On the idea of a warning, I don't really see the point; ?I find it hard to imagine it's really going to catch many real errors.

My experience is different.  In my work, NaNs often creep into
calculations that are not designed to deal with them. (More often from
data files than from invalid operations.)  Sorting a large list with a
handful of NaNs, often leads to rather mysterious errors if not to
silently wrong results.  I believe there was even an issue on the
tracker about this particular case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 21 22:02:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 20:02:08 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1306008128.12.0.816161030846.issue11949@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm, okay.  Call me +0 on the warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sat May 21 22:06:38 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 20:06:38 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1306008398.12.0.927534411587.issue11986@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> and it's dishonest to claim it is.

This language was going too far, and I apologise for it.  I think I need one of those 'wait 5 minutes before allowing you to post' controls.

----------
keywords: +gsoc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Sat May 21 22:17:45 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2011 20:17:45 +0000
Subject: [issue12127] Inconsistent leading zero treatment
In-Reply-To: <1305865184.0.0.372587654488.issue12127@psf.upfronthosting.co.za>
Message-ID: <1306009065.91.0.568094019747.issue12127@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It does look as though all the arguments were pretty thoroughly hashed out on the python-3000 list when this was first proposed.  See e.g., the thread starting at:

http://mail.python.org/pipermail/python-3000/2007-March/006262.html

and various follow-on threads.  I retract my suggestion that this should be discussed again on python-dev; it probably wouldn't achieve anything.

On the subject of other languages, I was rather hoping that more recent and enlightened languages would have done away with the leading zero implies octal business.  It looks as though C# has, at least, but I was a bit disappointed to see that Go still has leading-zero octal literals.  

For the old-school languages, I'd still expect that for most users this feature is more often a surprising gotcha than expected and useful.

http://stackoverflow.com/questions/565634/integer-with-leading-zeroes

Anyway, +0 for closing as 'rejected'.  (Or perhaps 'wont fix'.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12127>
_______________________________________

From report at bugs.python.org  Sat May 21 22:26:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 May 2011 20:26:54 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1306006347.99.0.00190259995193.issue11986@psf.upfronthosting.co.za>
Message-ID: <BANLkTik4r-jOvRA+3jpGsW8EJpTN_MasuQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, May 21, 2011 at 3:32 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> That might be viable (a math module function might also make sense here), though it feels a bit YAGNI to me.

I have to admit that it would be YAGNI for most of my code because it
uses numpy for numeric calculations.  Still, for consistency with
decimal, it may be a good addition.

Going a bit off-topic, I would like to mention the feature that may
actually be quite useful: float.sorting_key() that will return an
integer for each float in such a way that keys are ordered in IEEE 754
total ordering.  Note that decimal has compare_total() that can be
used for sorting, but a cmp-style method is less useful than a key
since in py3k sort does not take cmp function anymore.  Nice thing
about IEEE 754 is that  float.sorting_key()  can be implemented very
efficiently because one can simply use float's binary representation
interpreted as an integer for the key.

> ?If we were going to add such a method, it should follow IEEE 754: ?nan.max(x) == x.max(n) == x,
> but also nan.min(x) == x.min(nan) == x, for finite x. ?(See section 5.3.1.)

Agree.  Unfortunately, numpy does not do it that way:

nan
>>> maximum(1.0, nan)
nan

I am not sure whether this is an argument for or against
float.max/min: if numpy had properly defined maximum, I would just
recommend to use that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Sat May 21 22:34:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 May 2011 20:34:05 +0000
Subject: [issue12075] python3.2 memory leak when reloading class with
	attributes
In-Reply-To: <1305357392.12.0.709817768407.issue12075@psf.upfronthosting.co.za>
Message-ID: <1306010045.45.0.17975371621.issue12075@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> my class also inherits from subprocess.Popen, which has a __del__ method, which might interfere w/ collection

The doc says __del__ *will* prevent collection.

> (although gc.garbage says otherwise ;).

Do you mean that gc.garbage is empty, when it should not be?

Have you tried replacing __del__ with an explicit close or cleanup method?

----------
nosy: +terry.reedy
title: python3.2 memory leak when setting integer key in dictionary -> python3.2 memory leak when reloading class with attributes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12075>
_______________________________________

From report at bugs.python.org  Sat May 21 23:00:54 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 21:00:54 +0000
Subject: [issue12131] python built with --prefix fails in site.py with no
	section 'posix_prefix'
In-Reply-To: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>
Message-ID: <1306011654.45.0.646168108422.issue12131@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This seems to be the proper fix, I forgot to change the Makefile.  Would you mind applying it ? thanks

about editing this file: as mentioned on python dev, there will be several levels of customization (global, per project, per user)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12131>
_______________________________________

From report at bugs.python.org  Sun May 22 00:19:20 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 21 May 2011 22:19:20 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306016360.73.0.266791561413.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file22049/issue8898.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 00:19:48 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 21 May 2011 22:19:48 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306016388.66.0.702592475185.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22053/issue8898.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 00:19:55 2011
From: report at bugs.python.org (Philip Drew)
Date: Sat, 21 May 2011 22:19:55 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>


New submission from Philip Drew <pwtdrew at gmail.com>:

Upon execution of python.exe a command line box appears for a fraction of a second, closes and is followed by nothing. On executing IDLE from the start menu, nothing happens. I have installed python to C:\Python27 using the python windows installer.
I am running win7 64 bit on a toshiba satellite 17X

----------
components: IDLE, Installation
messages: 136481
nosy: Philip.Drew
priority: normal
severity: normal
status: open
title: Crash upon start up
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Sun May 22 00:22:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 May 2011 22:22:35 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306016555.27.0.648385265395.issue12140@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you try to open a Windows terminal (start->run->cmd or win+r on the keyboard), cd to Python27, execute python.exe and see if it gives any error message there?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Sun May 22 00:32:31 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 22:32:31 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

this test module looks for sysconfig.get_config_var('srcdir') which in turns uses the sys,executable path.

multiprocess seems to change it in every process, leading to the errors.

To reproduce:

./python Lib/test/regrtest.py -j2 -v test_packaging

A workaround is to skip the test in case the file is not found, but we need to fix it because it boils down to sysconfig being broken in multiprocess

----------
assignee: pitrou
messages: 136483
nosy: pitrou, tarek
priority: normal
severity: normal
status: open
title: --multiprocessing fails with packaging.tests.test_command_build_ext

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 00:34:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 22:34:26 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306017266.91.0.571327529148.issue12141@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What's the difference with issue12132?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 00:38:34 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 22:38:34 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1306017514.33.0.00201295783896.issue12132@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
superseder:  -> test_packaging failures when run with -j

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sun May 22 00:39:35 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 22:39:35 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1306017575.37.0.275766715654.issue12132@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
superseder: test_packaging failures when run with -j -> --multiprocessing fails with packaging.tests.test_command_build_ext

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sun May 22 00:39:48 2011
From: report at bugs.python.org (poq)
Date: Sat, 21 May 2011 22:39:48 +0000
Subject: [issue12142] Circular reference when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>


New submission from poq <poq at gmx.com>:

When importing ctypes after gc.set_debug(gc.DEBUG_LEAK), the garbage collector finds a 'c_int_Array_3' class and some related objects.

The class is created in ctypes/_endian.py:
_array_type = type(c_int * 3)

It seems that this could be avoided with:
_array_type = type(Array)

Of course, I realize this is not a bug because normally it will just get collected. It is just an extremely minor annoyance because this is currently the only thing still found by DEBUG_LEAK for my program ;)

----------
components: ctypes
messages: 136485
nosy: poq
priority: normal
severity: normal
status: open
title: Circular reference when importing ctypes
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12142>
_______________________________________

From report at bugs.python.org  Sun May 22 00:41:00 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 22:41:00 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306017660.32.0.415403113893.issue12141@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Oops. It's a duplicate. Keeping this one since the problem was narrowed to multiprocessing/sys,executable and sysconfig

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 00:41:04 2011
From: report at bugs.python.org (poq)
Date: Sat, 21 May 2011 22:41:04 +0000
Subject: [issue12142] eference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1306017664.85.0.0640437149225.issue12142@psf.upfronthosting.co.za>


Changes by poq <poq at gmx.com>:


----------
title: Circular reference when importing ctypes -> eference cycle when importing ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12142>
_______________________________________

From report at bugs.python.org  Sun May 22 00:41:11 2011
From: report at bugs.python.org (poq)
Date: Sat, 21 May 2011 22:41:11 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1306017671.4.0.941379590876.issue12142@psf.upfronthosting.co.za>


Changes by poq <poq at gmx.com>:


----------
title: eference cycle when importing ctypes -> Reference cycle when importing ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12142>
_______________________________________

From report at bugs.python.org  Sun May 22 00:41:22 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 22:41:22 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1306017682.91.0.435918915716.issue12132@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sun May 22 00:50:10 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 21 May 2011 22:50:10 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306018210.54.0.447555342386.issue12141@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/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 00:50:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 22:50:19 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306017660.32.0.415403113893.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306018215.3693.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Oops. It's a duplicate. Keeping this one since the problem was
> narrowed to multiprocessing/sys,executable and sysconfig

I don't think it has anything to do with sys.executable. As the other
issue says, it seems the test (or packaging/sysconfig itself) is simply
unable to locate the root of the current checkout (which should be
trivial using __file__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 00:51:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 May 2011 22:51:59 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306018319.76.0.231648422245.issue8898@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch looks ok to me.
AFAIU the lookup will take care to normalize the name and return latin_N.  This also implies that other names (like 'latin-N', 'LaTiN~~N' and so on) will be normalized to latin_N and then accepted.

Regarding the tests, I don't see tests for the aliases anywhere, so something like:
for alias, codec_name in encodings.aliases.items():
    self.assertEqual(codecs.lookup(alias).name, codec_name)
could be added somewhere to check that all the aliases in the dict map to the correct codec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 00:59:12 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 22:59:12 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306018752.19.0.177981262632.issue12141@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

sysconfig is looking for the source dir when 

  sysconfig.get_config_var('srcdir')

is called.

And this is done like this:


if sys.executable:
    _PROJECT_BASE = os.path.dirname(_safe_realpath(sys.executable))
else:
    # sys.executable can be empty if argv[0] has been changed and Python is
    # unable to retrieve the real program name
    _PROJECT_BASE = _safe_realpath(os.getcwd())


Because sys.executable (argv[0] in fact) is not filled when you call multiprocess vvia the -j option.

So yeah, this has to do with sys.executable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 01:07:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 May 2011 23:07:30 +0000
Subject: [issue12131] python built with --prefix fails in site.py with no
	section 'posix_prefix'
In-Reply-To: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>
Message-ID: <E1QNvGU-0008AE-KV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f37a4e1182d6 by Ned Deily in branch 'default':
Issue #12131: Ensure that the sysconfig.cfg file, introduced by packaging,
http://hg.python.org/cpython/rev/f37a4e1182d6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12131>
_______________________________________

From report at bugs.python.org  Sun May 22 01:10:11 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 May 2011 23:10:11 +0000
Subject: [issue12131] python built with --prefix fails in site.py with no
	section 'posix_prefix'
In-Reply-To: <1305947651.27.0.813030109711.issue12131@psf.upfronthosting.co.za>
Message-ID: <1306019411.16.0.277450089977.issue12131@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Applied as requested.

----------
assignee: tarek -> ned.deily
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12131>
_______________________________________

From report at bugs.python.org  Sun May 22 01:24:05 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 21 May 2011 23:24:05 +0000
Subject: [issue12143] packaging extension gcc linking fails on Ubuntu Shared
In-Reply-To: <1306020245.1.0.800902261417.issue12143@psf.upfronthosting.co.za>
Message-ID: <1306020245.1.0.800902261417.issue12143@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

I can't reproduce this yet, or compare it to distutils. I 

======================================================================
ERROR: test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 255, in link
    self.spawn(linker + ld_args)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 847, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/util.py", line 783, in spawn
    raise PackagingExecError(msg % (cmd, exit_status))
packaging.errors.PackagingExecError: command '['gcc', '-pthread', '-shared', '/tmp/tmpwe7ci9/tmp3v8m7p/tmp/tmpwe7ci9/tmp3v8m7p/xxmodule.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpwe7ci9/tmp3v8m7p/xx.cpython-33dm.so']' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/tests/test_command_build_ext.py", line 59, in test_build_ext
    cmd.run()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 368, in build_extensions
    self.build_extension(ext)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 454, in build_extension
    target_lang=language)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 675, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 257, in link
    raise LinkError(msg)
packaging.errors.LinkError: command '['gcc', '-pthread', '-shared', '/tmp/tmpwe7ci9/tmp3v8m7p/tmp/tmpwe7ci9/tmp3v8m7p/xxmodule.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpwe7ci9/tmp3v8m7p/xx.cpython-33dm.so']' failed with exit status 1

======================================================================
ERROR: test_get_outputs (packaging.tests.test_command_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 255, in link
    self.spawn(linker + ld_args)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 847, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/util.py", line 783, in spawn
    raise PackagingExecError(msg % (cmd, exit_status))
packaging.errors.PackagingExecError: command '['gcc', '-pthread', '-shared', '/tmp/tmpdfxahd/tmp0m_s9d/tempt/tmp/tmpdfxahd/tmp_cb75f/foo.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpdfxahd/tmpcoi8oo/foo.cpython-33dm.so']' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/tests/test_command_build_ext.py", line 263, in test_get_outputs
    cmd.run()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 368, in build_extensions
    self.build_extension(ext)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/command/build_ext.py", line 454, in build_extension
    target_lang=language)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/ccompiler.py", line 675, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/packaging/compiler/unixccompiler.py", line 257, in link
    raise LinkError(msg)
packaging.errors.LinkError: command '['gcc', '-pthread', '-shared', '/tmp/tmpdfxahd/tmp0m_s9d/tempt/tmp/tmpdfxahd/tmp_cb75f/foo.o', '-L.', '-lpython3.3', '-o', '/tmp/tmpdfxahd/tmpcoi8oo/foo.cpython-33dm.so']' failed with exit status 1

----------
assignee: tarek
components: Distutils2
messages: 136492
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: packaging extension gcc linking fails on Ubuntu Shared

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12143>
_______________________________________

From report at bugs.python.org  Sun May 22 01:24:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 May 2011 23:24:38 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306018752.19.0.177981262632.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306020275.3693.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Because sys.executable (argv[0] in fact) is not filled when you call
> multiprocess vvia the -j option.

sys.executable is set perfectly well when running regrtest in
multiprocess mode, otherwise many other tests would fail.

Try:
$ grep "sys.executable" Lib/test/*
Lib/test/regrtest.py:585:        base_cmd = [sys.executable] + opt_args + ['-m', 'test.regrtest']
Lib/test/script_helper.py:20:    cmd_line = [sys.executable]
Lib/test/script_helper.py:60:    cmd_line = [sys.executable, '-E']
Lib/test/test_base64.py:231:        args = (sys.executable, '-m', 'base64') + args
Lib/test/test_capi.py:42:        p = subprocess.Popen([sys.executable, "-c",
[etc.]

Again, it seems sysconfig simply has a bug which you can reproduce on
the command line:

$ pwd
/home/antoine/cpython/default/build
$ ../python -c "import sys, sysconfig; print(sys.executable,
sysconfig.get_config_var('srcdir'))"
/home/antoine/cpython/default/build/../python /home/antoine/cpython/default/build

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 01:46:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 May 2011 23:46:46 +0000
Subject: [issue12141] --multiprocessing fails with
	packaging.tests.test_command_build_ext
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <1306021606.82.0.929153806511.issue12141@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The test should be changed anyway to avoid the dependency on "srcdir", whose value has no meaning when the tests are not run from a simple in-source-directory build.  The test could create its own temp copy of xxmodule.c.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 02:51:01 2011
From: report at bugs.python.org (David Bolen)
Date: Sun, 22 May 2011 00:51:01 +0000
Subject: [issue12143] packaging extension gcc linking fails on Ubuntu Shared
In-Reply-To: <1306020245.1.0.800902261417.issue12143@psf.upfronthosting.co.za>
Message-ID: <1306025461.23.0.425509529341.issue12143@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

I just ran a manual build/test on the buildbot, and these underlying failures appear to be due to the "-l python3.3" option, which can't be found.  I also don't see that library in the build tree.  Instead, the library is built as python3.3dm (the buildbot process uses --with-pydebug and --with-pymalloc is now default in 3.2+).

Haven't dug much deeper than that, so not sure how the packaging tests are figuring out the shared library to link with.  I did verify that the sysconfig module variables that are related do all have the dm suffix information so it should be available to the tests.

-- David

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12143>
_______________________________________

From report at bugs.python.org  Sun May 22 03:14:27 2011
From: report at bugs.python.org (Brian May)
Date: Sun, 22 May 2011 01:14:27 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1306026867.06.0.283714694798.issue6560@psf.upfronthosting.co.za>


Brian May <brian at microcomaustralia.com.au> added the comment:

What needs to happen to get recvmsg() supported in Python?

recvmsg() is required to get get transparent UDP proxies working under Linux using tproxy, the code needs to run recvmsg() to be able to find out what the original destination address was for the the packet.

Thanks

Brian May

----------
nosy: +brian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Sun May 22 04:30:48 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2011 02:30:48 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1306031448.56.0.662806507582.issue11949@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Sun May 22 04:58:45 2011
From: report at bugs.python.org (Scott Wimer)
Date: Sun, 22 May 2011 02:58:45 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>


New submission from Scott Wimer <scott.wimer at gmail.com>:

When cookielib.CookieJar().make_cookies is used to extract cookies from a urllib2 response, it crashes when it encounters a 'Set-Cookie' header entry that has an 'expires' attribute.

This crash occurs because the expires time is evaluated against the '_now' attribute of the CookieJar instance -- an attribute which is not set unless CookieJar().extract_cookies() was called previously.

Attached is a script that triggers this bug.

----------
components: Library (Lib)
files: cookielib-crash.py
messages: 136497
nosy: Scott.Wimer
priority: normal
severity: normal
status: open
title: cookielib.CookieJar.make_cookies fails for cookies with 'expires' set
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file22054/cookielib-crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Sun May 22 05:07:56 2011
From: report at bugs.python.org (Scott Wimer)
Date: Sun, 22 May 2011 03:07:56 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1306033676.05.0.763721422351.issue12144@psf.upfronthosting.co.za>


Scott Wimer <scott.wimer at gmail.com> added the comment:

The actual error is triggered by line 1507 in '_cookie_from_cookie_tuple()'.

An easy fix is to move the setting of '_now' on line 1636 into the 'make_cookies()' method.

That addresses this problem and doesn't look like it would introduce any negative side effects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Sun May 22 05:09:41 2011
From: report at bugs.python.org (Scott Wimer)
Date: Sun, 22 May 2011 03:09:41 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1306033781.94.0.206644198859.issue12144@psf.upfronthosting.co.za>


Scott Wimer <scott.wimer at gmail.com> added the comment:

Forgot to include the patch. Oops.

----------
keywords: +patch
Added file: http://bugs.python.org/file22055/cookielib-crash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Sun May 22 05:10:55 2011
From: report at bugs.python.org (Daniel Lindsley)
Date: Sun, 22 May 2011 03:10:55 +0000
Subject: [issue12145] distutils2 should support README.rst
In-Reply-To: <1306033855.22.0.0348885298579.issue12145@psf.upfronthosting.co.za>
Message-ID: <1306033855.22.0.0348885298579.issue12145@psf.upfronthosting.co.za>


New submission from Daniel Lindsley <daniel at toastdriven.com>:

Given that reST is the format all of Python's docs are in, it'd be nice if distutils(2) would support looking for README.rst (in addition to the existing README & README.txt).

----------
assignee: tarek
components: Distutils2
messages: 136500
nosy: alexis, daniellindsley, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2 should support README.rst
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12145>
_______________________________________

From report at bugs.python.org  Sun May 22 05:43:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 03:43:36 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

>From the docs maillist, by Herman L. Jackson:

-------------------

Hi,

When running the tokenize example at the bottom of http://docs.python.org/py3k/library/re.html#match-objects
I received the following error:

   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File "<stdin>", line 23, in tokenize
   NameError: global name 'val' is not defined

The problem is that val is never assigned to before this line:

   if typ == 'ID' and val in keywords:

Here is a suggested rewrite of the that section:

   elif typ != 'SKIP':
       val = mo.group(typ)
       if typ == 'ID' and val in keywords:
           typ = val
       yield Token(typ, val, line, mo.start()-line_start)

Attached is a complete working example.

----------
assignee: eli.bendersky
components: Documentation
files: tokenize.py
keywords: easy
messages: 136501
nosy: eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: Possible bug in 're' documentation example
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22056/tokenize.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 05:44:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 03:44:45 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306035885.01.0.536869468195.issue12146@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
assignee: eli.bendersky -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 05:49:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 03:49:22 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <E1QNzfM-00063Y-L5@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c0a3e17e677f by Eli Bendersky in branch '2.7':
Issue 12126: removing incorrect claim about return value of select
http://hg.python.org/cpython/rev/c0a3e17e677f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sun May 22 06:00:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 04:00:12 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <E1QNzpq-0006hg-W1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ca4d9ccb6894 by Eli Bendersky in branch '3.1':
Issue 12126: removing incorrect claim about return value of select
http://hg.python.org/cpython/rev/ca4d9ccb6894

New changeset c26d551b5ff6 by Eli Bendersky in branch '3.2':
Issue 12126: removing incorrect claim about return value of select
http://hg.python.org/cpython/rev/c26d551b5ff6

New changeset 53242ca6df28 by Eli Bendersky in branch 'default':
Issue 12126: removing incorrect claim about return value of select
http://hg.python.org/cpython/rev/53242ca6df28

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Sun May 22 06:09:01 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 04:09:01 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306037341.3.0.637608015026.issue12146@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The Tokenizer example seems to have appeared in 3.2, it's not present in 3.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 06:11:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2011 04:11:22 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306037482.38.0.873327299057.issue12146@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/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 06:24:21 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 04:24:21 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306038261.79.0.908387882268.issue12146@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

This was fixed by Georg in 538a6b23b18f and 12a2c1085621

----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 06:24:35 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 04:24:35 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306038275.88.0.0923681824571.issue12146@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/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 06:27:03 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 04:27:03 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306038423.75.0.982684278222.issue12146@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Raymond, I see you assigned the issue to yourself. The assignment was removed by mistake when I closed the issue - is this still something you need to look at?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 08:48:08 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 06:48:08 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1306018319.76.0.231648422245.issue8898@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=-5i7PZP2q1jiYmqV3f-UBDg4T0w@mail.gmail.com>


Michele Orr?? <maker.py at gmail.com> added the comment:

Well, actually encodings.aliases links to the encoding _module name_, as
described in the doc:
""" Encoding Aliases Support
    This module is used by the encodings package search function to
    map encodings names to module names.
"""
So I've adjusted your snippet according to this, as you can see in the
attachment.

I've also slightly changed the imports as pep8 says:
"""
Yes: import os
import sys

No: import sys, os
"""

Anyway, running the test failed for two encodings, there are two bugs there,
indeed.
- mcbs has something broken in its imports;
- tactis module is not present.

Since they are really easy to fix, I haven't yet reported to the bugtraker.
Let me know what should I do.
Post on bugs.python.org bug and patch? Any new test specifically for the
email module?

----------
Added file: http://bugs.python.org/file22057/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>??Regarding the tests, I don&#39;t see tests for the aliases anywhere, so something like:<br>



for alias, codec_name in encodings.aliases.items():<br>
 ?? ??self.assertEqual(codecs.lookup(alias).name, codec_name)<br>
could be added somewhere to check that all the aliases in the dict map to the correct codec.<br></blockquote>Well, actually encodings.aliases links to the encoding _module name_, as described in the doc:<br>&quot;&quot;&quot; Encoding Aliases Support<br>

?? ?? This module is used by the encodings package search function to<br>?? ?? map encodings names to module names.<br>&quot;&quot;&quot;<br>So I&#39;ve adjusted your snippet according to this, as you can see in the attachment.</div>

<div class="gmail_quote"><br>I&#39;ve also slightly changed the imports as pep8 says:<br>&quot;&quot;&quot;<br>        Yes: import os<br>             import sys<br><br>        No:  import sys, os<div>&quot;&quot;&quot;</div>

<div><br></div><div>Anyway, running the test failed for two encodings, there are two bugs there, indeed.</div><div>- mcbs has something broken in its imports;</div><div>- tactis module is not present.</div><div><br></div>

<div>Since they are really easy to fix, I haven&#39;t yet reported to the bugtraker. Let me know what should I do.</div><div>Post on <a href="http://bugs.python.org">bugs.python.org</a> bug and patch? Any new test specifically for the email module?</div>

<div><br></div></div>-- <br>Michele Orr??<br>

From report at bugs.python.org  Sun May 22 08:48:09 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 06:48:09 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306046889.45.0.503860669874.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22058/fail_tactis.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 08:48:39 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 06:48:39 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306046919.28.0.824165356072.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22059/issue8898_withtests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 08:49:03 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 06:49:03 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306046943.83.0.661390048787.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22060/fail_mcbs.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 09:54:41 2011
From: report at bugs.python.org (Nicolas Estibals)
Date: Sun, 22 May 2011 07:54:41 +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: <1306050881.77.0.236550216984.issue12147@psf.upfronthosting.co.za>


New submission from Nicolas Estibals <nicolas.estibals at gmail.com>:

smtplib.send_message permits to send messages that are in python Message representation by selecting smtp's "from" and "to" in the message headers. Most of the time the implementation is correct but if the message is bounced (Resent-* headers have to be considered) or if there is a Sender field (this one supersede the From field if present), the current implementation does not select the right addresses (not as specified in rfc 2822).

I have wrote a patch to make the method compliant. This is my first patch to python but I followed the "Lifecycle of a Patch" webpage and hope my code will be usable. Please ask me if some revision of the code is needed.

----------
components: Library (Lib)
files: send_message_rfc2822.patch
keywords: patch
messages: 136508
nosy: Nicolas.Estibals
priority: normal
severity: normal
status: open
title: smtplib.send_message does not implement corectly rfc 2822
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22061/send_message_rfc2822.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Sun May 22 12:09:26 2011
From: report at bugs.python.org (ekorn)
Date: Sun, 22 May 2011 10:09:26 +0000
Subject: [issue12148] Clarify "or-ing together" doctest option flags
In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>
Message-ID: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>


New submission from ekorn <jonovik at gmail.com>:

Combining multiple option flags to doctest.testmod(optionflags=...) requires the bitwise or operator |, not plain "or". I therefore suggest rewording "or-ing together individual option flags." to "or-ing together individual option flags, using the 'bitwise or' operator |.", perhaps with a link to http://docs.python.org/reference/expressions.html#binary-bitwise-operations.

Example:

"""
Doctest option flags must be or-ed together with '|', not 'or'.

>>> print "A  B  C"
A B...
"""
import doctest

print "Combining option flags using bitwise '|'..."
doctest.testmod(optionflags=doctest.NORMALIZE_WHITESPACE | doctest.ELLIPSIS)
print "Combining option flags using logical 'or'..."
doctest.testmod(optionflags=doctest.NORMALIZE_WHITESPACE or doctest.ELLIPSIS)

----------
assignee: docs at python
components: Documentation
messages: 136509
nosy: docs at python, ekorn
priority: normal
severity: normal
status: open
title: Clarify "or-ing together" doctest option flags
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12148>
_______________________________________

From report at bugs.python.org  Sun May 22 12:45:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 22 May 2011 10:45:42 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1306061142.36.0.515603172758.issue1441530@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Digging a little deeper, here's the conclusion:
- with py3k, fragmentation is less likely: the buffered reader returned by makefile() ensures that we can allocate only one result buffer for the total number of bytes read() (thanks to socket's readinto()). It's also faster. Finally, since buffered read() guarantees to return exactly the number of bytes asked, there's no need to call it repeatedly with min(size-read, 4096): it's slower, and actually makes fragmentation more likely.
So I've attached a patch removing the looping from py3k IMAP4 read() method, which leads to simpler, faster and fragmentation-less code.
- for 2.7, it's also better to wrap the SSL socket with makefile(): the leads to simpler code (no need to loop), and also I noticed that socket's _fileobject's (returned by makefile()) read() and readline() methods already use a StringIO to avoid fragmentation.
So I've attached a second patch wrapping 2.7 IMAP4_SSL socket with makefile.

While I can't reproduce this issue on my system, I've analyzed malloc/realloc/free calls using ltrace, and I'm pretty confident this should solve fragmentation issues for both 2.7 and py3k.

By the way, nice work with the I/O stack in py3k, the new layer allows much more efficient code (reduced allocations and copies)!

----------
Added file: http://bugs.python.org/file22062/imaplib_recv_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sun May 22 12:46:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 22 May 2011 10:46:14 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1306061174.12.0.314143530753.issue1441530@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22063/imaplib_recv_27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sun May 22 12:46:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 22 May 2011 10:46:34 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1306061194.55.0.494060897082.issue1441530@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22044/imaplib_read.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sun May 22 12:46:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 22 May 2011 10:46:55 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1306061215.09.0.288909765635.issue1441530@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22051/imaplib_ssl_makefile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sun May 22 13:13:11 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 22 May 2011 11:13:11 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <BANLkTi=-5i7PZP2q1jiYmqV3f-UBDg4T0w@mail.gmail.com>
Message-ID: <4DD8EFC4.60302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Michele Orr? wrote:
> 
> Michele Orr?? <maker.py at gmail.com> added the comment:
> 
> Well, actually encodings.aliases links to the encoding _module name_, as
> described in the doc:
> """ Encoding Aliases Support
>     This module is used by the encodings package search function to
>     map encodings names to module names.
> """
> So I've adjusted your snippet according to this, as you can see in the
> attachment.
> 
> I've also slightly changed the imports as pep8 says:
> """
> Yes: import os
> import sys
> 
> No: import sys, os
> """
> 
> Anyway, running the test failed for two encodings, there are two bugs there,
> indeed.
> - mcbs has something broken in its imports;

mbcs is only available on Windows.

> - tactis module is not present.

I'm not sure what happened here: either the alias entry is wrong
or the codec module was not committed.

In either case, no one has complained about this encoding not working,
so we can probably just remove it from the alias table. See
http://bugs.python.org/issue1251921 for a similar report and
discussion.

----------
title: The email package should defer to the codecs module for all aliases -> The email package should defer to the codecs module for	all aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 13:17:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 11:17:09 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306063029.65.0.613193889351.issue5715@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Sun May 22 13:23:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 11:23:14 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <E1QO6ka-0007Zx-MN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d5771ed4ec4e by Victor Stinner in branch '2.7':
Issue #12012: test_ssl uses test_support.import_module()
http://hg.python.org/cpython/rev/d5771ed4ec4e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Sun May 22 13:23:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 11:23:52 +0000
Subject: [issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d:
	SSLv2_method is missing
In-Reply-To: <1304638541.01.0.0335102300468.issue12012@psf.upfronthosting.co.za>
Message-ID: <1306063432.85.0.184924347124.issue12012@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, you broke the Solaris gcc buildbot on 2.7.

It should be fixed by d5771ed4ec4e.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12012>
_______________________________________

From report at bugs.python.org  Sun May 22 13:32:53 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 11:32:53 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <4DD8EFC4.60302@egenix.com>
Message-ID: <BANLkTikVHPG7efsWvDGcMcmiAsRYNam+cQ@mail.gmail.com>


Michele Orr?? <maker.py at gmail.com> added the comment:

So, what do you prefer? Add a check for sys.platform, or just skip it?

discussion on python-dev. So I'm +1 for just skipping it for now (with a XXX
comment on the right maybe).

----------
title: The email package should defer to the codecs module for	all aliases -> The email package should defer to the codecs module for all aliases
Added file: http://bugs.python.org/file22064/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________
-------------- next part --------------
<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"><br>
&gt; - mcbs has something broken in its imports;<br>
<br>
</div>mbcs is only available on Windows.<br></blockquote><div>So, what do you prefer? Add a check for sys.platform, or just skip it?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<div class="im"><br>
&gt; - tactis module is not present.<br>
<br>
</div>I&#39;m not sure what happened here: either the alias entry is wrong<br>
or the codec module was not committed.<br>
<br>
In either case, no one has complained about this encoding not working,<br>
so we can probably just remove it from the alias table. See<br>
<a href="http://bugs.python.org/issue1251921" target="_blank">http://bugs.python.org/issue1251921</a> for a similar report and<br>
discussion.<br>
<br></blockquote><div>I don&#39;t have such autority, and probably such a choice will require a discussion on python-dev. So I&#39;m +1 for just skipping it for now (with a XXX comment on the right maybe).</div><div><br>

</div><div><br></div></div>-- <br>Michele Orr??<br>

From report at bugs.python.org  Sun May 22 13:37:16 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 11:37:16 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306064236.74.0.54433733221.issue8898@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Sorry, I was told that email the bugtracker could not work properly.


> > - mcbs has something broken in its imports;

> mbcs is only available on Windows.
So, what do you prefer? Add a check for sys.platform, or just skip it?

> > - tactis module is not present.

> I'm not sure what happened here: either the alias entry is wrong
> or the codec module was not committed.

> In either case, no one has complained about this encoding not working,
> so we can probably just remove it from the alias table. See
> http://bugs.python.org/issue1251921 for a similar report and
> discussion.

I don't have such autority, and probably such a choice will require a discussion on python-dev. So I'm +1 for just skipping it for now (with a XXX comment on the right maybe).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 13:38:01 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 11:38:01 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306064281.08.0.534511102396.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file22057/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 13:53:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 11:53:36 +0000
Subject: [issue12079] decimal.py: TypeError precedence in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <E1QO7Dz-0001Jr-Jd@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 825b4278a055 by Mark Dickinson in branch 'default':
Issue #12079: Decimal(0).fma(Decimal('inf'), 'not a number') should give a TypeError, not a Decimal.InvalidOperation
http://hg.python.org/cpython/rev/825b4278a055

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12079>
_______________________________________

From report at bugs.python.org  Sun May 22 13:56:23 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 22 May 2011 11:56:23 +0000
Subject: [issue12079] decimal.py: TypeError precedence in fma()
In-Reply-To: <1305445806.46.0.358747120813.issue12079@psf.upfronthosting.co.za>
Message-ID: <1306065383.34.0.296344181698.issue12079@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It turns out that this is as simple as moving the _convert_other call to the top of the Decimal.fma method.  (For some reason I was confusing this with the subtleties involved in making sure that an InvalidOperation arising from the multiplication part of the fma takes precedence over an InvalidOperation coming from a signalling nan in the addend.)

Fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12079>
_______________________________________

From report at bugs.python.org  Sun May 22 13:58:44 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 22 May 2011 11:58:44 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1306064236.74.0.54433733221.issue8898@psf.upfronthosting.co.za>
Message-ID: <4DD8FA72.3070208@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Michele Orr? wrote:
> 
> Michele Orr? <maker.py at gmail.com> added the comment:
> 
> Sorry, I was told that email the bugtracker could not work properly.
> 
> 
>>> - mcbs has something broken in its imports;
> 
>> mbcs is only available on Windows.
>
> So, what do you prefer? Add a check for sys.platform, or just skip it?

The test suite provides ways to implement known failures on
specific platforms, so I'd suggest to use those mechanisms.
I've never used those, so can't comment on how much work it is
to use them.

If that's too difficult, just use sys.platform.

>>> - tactis module is not present.
> 
>> I'm not sure what happened here: either the alias entry is wrong
>> or the codec module was not committed.
> 
>> In either case, no one has complained about this encoding not working,
>> so we can probably just remove it from the alias table. See
>> http://bugs.python.org/issue1251921 for a similar report and
>> discussion.
> 
> I don't have such autority, and probably such a choice will require a discussion on python-dev. So I'm +1 for just skipping it for now (with a XXX comment on the right maybe).

Given the old discussion on the other ticket, it's fine to
remove the alias entry:

    # tactis codec
    'tis260'             : 'tactis',

----------
title: The email package should defer to the codecs module for all aliases -> The email package should defer to the codecs module for	all aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 14:26:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 12:26:56 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1306067216.2.0.673751240068.issue6560@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +charles-francois.natali, rosslagerwall
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Sun May 22 14:27:10 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 12:27:10 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <4DD8FA72.3070208@egenix.com>
Message-ID: <BANLkTin03RgFMFKZhJ_Seg4-qhgmWh7hvQ@mail.gmail.com>


Michele Orr?? <maker.py at gmail.com> added the comment:

unittest.skip* are decorators, so useless in this case; also, AFAIS
Lib/test/ uses sys.platform.

I would suggest to put a try statement in encodings.mbcs, and raise an
error in case the imported modules imported are not found.
But this is another story.

----------
title: The email package should defer to the codecs module for	all aliases -> The email package should defer to the codecs module for all aliases
Added file: http://bugs.python.org/file22065/issue8898_skip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________
-------------- next part --------------
diff -r cc60d0283fad Lib/email/charset.py
--- a/Lib/email/charset.py	Fri May 20 16:55:06 2011 +0200
+++ b/Lib/email/charset.py	Sun May 22 14:18:05 2011 +0200
@@ -10,6 +10,7 @@
     ]
 
 from functools import partial
+from codecs import lookup
 
 import email.base64mime
 import email.quoprimime
@@ -63,36 +64,6 @@
     'utf-8':       (SHORTEST,  BASE64, 'utf-8'),
     }
 
-# Aliases for other commonly-used names for character sets.  Map
-# them to the real ones used in email.
-ALIASES = {
-    'latin_1': 'iso-8859-1',
-    'latin-1': 'iso-8859-1',
-    'latin_2': 'iso-8859-2',
-    'latin-2': 'iso-8859-2',
-    'latin_3': 'iso-8859-3',
-    'latin-3': 'iso-8859-3',
-    'latin_4': 'iso-8859-4',
-    'latin-4': 'iso-8859-4',
-    'latin_5': 'iso-8859-9',
-    'latin-5': 'iso-8859-9',
-    'latin_6': 'iso-8859-10',
-    'latin-6': 'iso-8859-10',
-    'latin_7': 'iso-8859-13',
-    'latin-7': 'iso-8859-13',
-    'latin_8': 'iso-8859-14',
-    'latin-8': 'iso-8859-14',
-    'latin_9': 'iso-8859-15',
-    'latin-9': 'iso-8859-15',
-    'latin_10':'iso-8859-16',
-    'latin-10':'iso-8859-16',
-    'cp949':   'ks_c_5601-1987',
-    'euc_jp':  'euc-jp',
-    'euc_kr':  'euc-kr',
-    'ascii':   'us-ascii',
-    }
-
-
 # Map charsets to their Unicode codec strings.
 CODEC_MAP = {
     'gb2312':      'eucgb2312_cn',
@@ -103,6 +74,8 @@
     'us-ascii':    None,
     }
 
+# Aliases defined by the user
+ALIASES = dict()
 
 
 # Convenience functions for extending the above mappings
@@ -220,9 +193,12 @@
                 input_charset = str(input_charset, 'ascii')
         except UnicodeError:
             raise errors.CharsetError(input_charset)
-        input_charset = input_charset.lower()
-        # Set the input charset after filtering through the aliases
-        self.input_charset = ALIASES.get(input_charset, input_charset)
+        # Set the input charset after filtering through its aliases defined in
+        # codecs library
+        try:
+            self.input_charset = lookup(input_charset).name
+        except LookupError:
+            self.input_charset = ALIASES.get(input_charset, input_charset)
         # We can try to guess which encoding and conversion to use by the
         # charset_map dictionary.  Try that first, but let the user override
         # it.
diff -r cc60d0283fad Lib/encodings/aliases.py
--- a/Lib/encodings/aliases.py	Fri May 20 16:55:06 2011 +0200
+++ b/Lib/encodings/aliases.py	Sun May 22 14:18:05 2011 +0200
@@ -254,7 +254,7 @@
     # hp_roman8 codec
     'roman8'             : 'hp_roman8',
     'r8'                 : 'hp_roman8',
-    'csHPRoman8'         : 'hp_roman8',
+    'cshproman8'         : 'hp_roman8',
 
     # hz codec
     'hzgb'               : 'hz',
@@ -298,6 +298,7 @@
     'iso_ir_157'         : 'iso8859_10',
     'l6'                 : 'iso8859_10',
     'latin6'             : 'iso8859_10',
+    'latin_6'            : 'iso8859_10',
 
     # iso8859_11 codec
     'thai'               : 'iso8859_11',
@@ -308,6 +309,7 @@
     'iso_8859_13'        : 'iso8859_13',
     'l7'                 : 'iso8859_13',
     'latin7'             : 'iso8859_13',
+    'latin_7'            : 'iso8859_13',
 
     # iso8859_14 codec
     'iso_8859_14'        : 'iso8859_14',
@@ -316,11 +318,13 @@
     'iso_ir_199'         : 'iso8859_14',
     'l8'                 : 'iso8859_14',
     'latin8'             : 'iso8859_14',
+    'latin_8'            : 'iso8859_14',
 
     # iso8859_15 codec
     'iso_8859_15'        : 'iso8859_15',
     'l9'                 : 'iso8859_15',
     'latin9'             : 'iso8859_15',
+    'latin_9'            : 'iso8859_15',
 
     # iso8859_16 codec
     'iso_8859_16'        : 'iso8859_16',
@@ -328,6 +332,7 @@
     'iso_ir_226'         : 'iso8859_16',
     'l10'                : 'iso8859_16',
     'latin10'            : 'iso8859_16',
+    'latin_10'           : 'iso8859_16',
 
     # iso8859_2 codec
     'csisolatin2'        : 'iso8859_2',
@@ -336,6 +341,7 @@
     'iso_ir_101'         : 'iso8859_2',
     'l2'                 : 'iso8859_2',
     'latin2'             : 'iso8859_2',
+    'latin_2'            : 'iso8859_2',
 
     # iso8859_3 codec
     'csisolatin3'        : 'iso8859_3',
@@ -344,6 +350,7 @@
     'iso_ir_109'         : 'iso8859_3',
     'l3'                 : 'iso8859_3',
     'latin3'             : 'iso8859_3',
+    'latin_3'            : 'iso8859_3',
 
     # iso8859_4 codec
     'csisolatin4'        : 'iso8859_4',
@@ -352,6 +359,7 @@
     'iso_ir_110'         : 'iso8859_4',
     'l4'                 : 'iso8859_4',
     'latin4'             : 'iso8859_4',
+    'latin_4'            : 'iso8859_4',
 
     # iso8859_5 codec
     'csisolatincyrillic' : 'iso8859_5',
@@ -393,6 +401,7 @@
     'iso_ir_148'         : 'iso8859_9',
     'l5'                 : 'iso8859_9',
     'latin5'             : 'iso8859_9',
+    'latin_5'            : 'iso8859_9',
 
     # johab codec
     'cp1361'             : 'johab',
@@ -474,9 +483,6 @@
     'sjisx0213'          : 'shift_jisx0213',
     's_jisx0213'         : 'shift_jisx0213',
 
-    # tactis codec
-    'tis260'             : 'tactis',
-
     # tis_620 codec
     'tis620'             : 'tis_620',
     'tis_620_0'          : 'tis_620',
diff -r cc60d0283fad Lib/test/test_codeccallbacks.py
--- a/Lib/test/test_codeccallbacks.py	Fri May 20 16:55:06 2011 +0200
+++ b/Lib/test/test_codeccallbacks.py	Sun May 22 14:18:05 2011 +0200
@@ -1,5 +1,13 @@
-import test.support, unittest
-import sys, codecs, html.entities, unicodedata
+import test.support
+import unittest
+
+from  encodings.aliases import aliases
+import codecs
+import unicodedata
+import html.entities
+import importlib
+import sys
+
 
 class PosReturn:
     # this can be used for configurable callbacks
@@ -629,7 +637,16 @@
                     "test.badhandler"
                 )
 
-    def test_lookup(self):
+    def test_lookup_aliases(self):
+        for alias, module_name in aliases.items():
+            if sys.platform != 'win32' and module_name == 'mbcs':
+                continue
+
+            module = importlib.import_module('encodings.' + module_name)
+            codec_name = module.getregentry().name
+            self.assertEqual(codecs.lookup(alias).name, codec_name)
+
+    def test_lookup_error(self):
         self.assertEqual(codecs.strict_errors, codecs.lookup_error("strict"))
         self.assertEqual(codecs.ignore_errors, codecs.lookup_error("ignore"))
         self.assertEqual(codecs.strict_errors, codecs.lookup_error("strict"))
@@ -664,7 +681,7 @@
         self.assertRaises(TypeError, codecs.register_error, 42)
         self.assertRaises(TypeError, codecs.register_error, "test.dummy", 42)
 
-    def test_badlookupcall(self):
+    def test_badlookup_errorcall(self):
         # enhance coverage of:
         # Modules/_codecsmodule.c::lookup_error()
         self.assertRaises(TypeError, codecs.lookup_error)

From report at bugs.python.org  Sun May 22 14:36:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 May 2011 12:36:01 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306067761.58.0.492576493765.issue8898@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Something like:
if name == 'mbcs' and not sys.platform.startswith('win'):
    continue
should be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 14:43:54 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 12:43:54 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306068234.54.0.507888517937.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file22065/issue8898_skip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 14:44:08 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 12:44:08 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306068248.58.0.816226753003.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22066/issue8898_skip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 14:54:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 May 2011 12:54:01 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306068841.43.0.713327306589.issue8898@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I suggest to:
  1) remove the alias for tactis;
  2) add the aliases for latin_* and the tests for the aliases;
  3) fix the email.charset to use the new aliases instead of its own dict.

2) and 3) should go on 3.3 only, 1) could be considered a bug and fixed on 2.7/3.2 too, but since the codec is already missing, removing the alias won't change anything (i.e. it will raise a LookupError with or without alias).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 14:54:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 May 2011 12:54:52 +0000
Subject: [issue12148] Clarify "or-ing together" doctest option flags
In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>
Message-ID: <1306068892.92.0.417359408197.issue12148@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think adding the word 'bitwise' in front of "or'ed" and linking it to that section would be sufficient.

----------
nosy: +r.david.murray
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12148>
_______________________________________

From report at bugs.python.org  Sun May 22 15:42:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 13:42:51 +0000
Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on
	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1306071771.39.0.295440769511.issue12073@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Update the patch and describe the new feature in regrtest doc (--help).

----------
Added file: http://bugs.python.org/file22067/regrtest_sigusr1-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12073>
_______________________________________

From report at bugs.python.org  Sun May 22 15:44:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 13:44:17 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec at
	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1306071857.82.0.409367448332.issue12100@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Sun May 22 15:51:32 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 22 May 2011 13:51:32 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1306072292.19.0.0160540322777.issue12080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch. Stefan, could you please review?

----------
keywords: +patch
Added file: http://bugs.python.org/file22068/issue12080.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12080>
_______________________________________

From report at bugs.python.org  Sun May 22 15:51:58 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 22 May 2011 13:51:58 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1306072318.29.0.118269115673.issue12080@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12080>
_______________________________________

From report at bugs.python.org  Sun May 22 15:56:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 13:56:41 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306072601.08.0.205539966717.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@charles-francois.natali: Your patch is ok, you can commit it into 3.1, 3.2, 3.3. But you may wait after 3.2.1.

@Georg Brandl: Should we wait after Python 3.2.1 for this issue?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 15:58:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 13:58:59 +0000
Subject: [issue12103] Documentation of open() does not claim 'e' support in
	mode string
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1306072739.84.0.96987271517.issue12103@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #12105 adds os.O_CLOEXEC flag, so we will be able to write open(os.open(filename, os.O_RDONLY|os.O_CLOEXEC)). Do you want to work on a doc patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12103>
_______________________________________

From report at bugs.python.org  Sun May 22 16:00:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 14:00:30 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306072830.12.0.241781260225.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> open() documentation may explain the os.fdopen(os.open()) "trick"
>> to use low-level options like O_SYNC or O_CLOEXEC.

> Why not, but I leave it to someone more comfortable with 
> documentation than me :-)

Issue #12103 should be fine for this idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 16:04:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 14:04:29 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306073069.79.0.608169660551.issue5715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't know if it's related, but SimpleXMLRPCServer in Python 2.7 uses fcntl(self.fileno(), fcntl.F_SETFD, flags):

class SimpleXMLRPCServer(SocketServer.TCPServer,
                         SimpleXMLRPCDispatcher):
    ...
    def __init__(self, ...):
        ...
        # [Bug #1222790] If possible, set close-on-exec flag; if a
        # method spawns a subprocess, the subprocess shouldn't have
        # the listening socket open.
        if fcntl is not None and hasattr(fcntl, 'FD_CLOEXEC'):
            flags = fcntl.fcntl(self.fileno(), fcntl.F_GETFD)
            flags |= fcntl.FD_CLOEXEC
            fcntl.fcntl(self.fileno(), fcntl.F_SETFD, flags)

=> see also issue #1222790.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Sun May 22 16:07:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 14:07:01 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306073221.48.0.692651180345.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, by the way: it would also be nice to add os.O_CLOEXEC to Python 2.7.

For example, tempfile._mkstemp_inner() uses:
            fd = _os.open(file, flags, 0600)
            _set_cloexec(fd) #?fcntl(fd, F_SETFD, flags | FD_CLOEXEC)
which is not atomic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 16:14:40 2011
From: report at bugs.python.org (Philip Drew)
Date: Sun, 22 May 2011 14:14:40 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306073680.31.0.342701494547.issue12140@psf.upfronthosting.co.za>


Philip Drew <pwtdrew at gmail.com> added the comment:

The error message is:
ImportError: No module named site.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Sun May 22 16:25:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 May 2011 14:25:41 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306074341.53.0.41592638653.issue12140@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The 'site' module should be in Python27\Lib\site.py.
You could try to run "python.exe -v" to see if it says something useful in the output, or maybe try to reinstall Python and see if it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Sun May 22 16:53:21 2011
From: report at bugs.python.org (Philip Drew)
Date: Sun, 22 May 2011 14:53:21 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306076001.63.0.241373510652.issue12140@psf.upfronthosting.co.za>


Philip Drew <pwtdrew at gmail.com> added the comment:

The site module is in the right place
This is what I got running the -v flag: (I don't know what you're looking for)

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\PWTD>c:\Python27\python.exe -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
ImportError: No module named site
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.flags
# clear sys.float_info
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] zipimport
# cleanup[1] signal
# cleanup[1] exceptions
# cleanup[1] _warnings
# cleanup sys
# cleanup __builtin__
# cleanup ints: 6 unfreed ints
# cleanup floats

C:\Users\PWTD>c:\Python27\python.exe
ImportError: No module named site

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Sun May 22 16:54:27 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 22 May 2011 14:54:27 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1306068841.43.0.713327306589.issue8898@psf.upfronthosting.co.za>
Message-ID: <4DD923A1.8060105@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:
> 
> I suggest to:
>   1) remove the alias for tactis;
>   2) add the aliases for latin_* and the tests for the aliases;
>   3) fix the email.charset to use the new aliases instead of its own dict.
> 
> 2) and 3) should go on 3.3 only, 1) could be considered a bug and fixed on 2.7/3.2 too, but since the codec is already missing, removing the alias won't change anything (i.e. it will raise a LookupError with or without alias).

+1

----------
title: The email package should defer to the codecs module for all aliases -> The email package should defer to the codecs module for	all aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 17:02:13 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 22 May 2011 15:02:13 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec at
	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1306076533.77.0.324791748666.issue12100@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think it's better to use a StringIO instance for the tests.

Regarding resetting the incremental codec every time .encode() is called: Hye-Shik will have to comment. Perhaps there's an internal reason why they do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Sun May 22 17:07:18 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 22 May 2011 15:07:18 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306076838.86.0.998398194266.issue12105@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

One moment -- adding a new value to the os module looks like a new feature to me.  Is there any convincing reason why this needs to go to 3.2?  (And it most definitely shouldn't go to 3.1.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 17:10:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 22 May 2011 15:10:22 +0000
Subject: [issue12080] decimal.py: performance in _power_exact
In-Reply-To: <1305448101.95.0.153633212441.issue12080@psf.upfronthosting.co.za>
Message-ID: <1306077022.99.0.0576083248377.issue12080@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a slightly improved version that adds guards against computing 10**ye for large ye in the case y < 0, ye > 0.

----------
Added file: http://bugs.python.org/file22069/issue12080_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12080>
_______________________________________

From report at bugs.python.org  Sun May 22 17:18:08 2011
From: report at bugs.python.org (s7v7nislands)
Date: Sun, 22 May 2011 15:18:08 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1306077488.61.0.00315822345155.issue9942@psf.upfronthosting.co.za>


Changes by s7v7nislands <s7v7nislands at gmail.com>:


----------
nosy: +s7v7nislands

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Sun May 22 17:20:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 15:20:53 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306077653.75.0.280757867496.issue12105@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

No reason. I think this is definitely 3.3 material.

----------
nosy: +pitrou
versions:  -Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 17:23:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 15:23:42 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306077822.05.0.528057803927.issue5715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch looks fine to me. Is it easily testable?

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Sun May 22 17:34:54 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 15:34:54 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <4DD923A1.8060105@egenix.com>
Message-ID: <BANLkTi=+OjDZzkXTpScP-da5aJo6GET83A@mail.gmail.com>


Michele Orr? <maker.py at gmail.com> added the comment:

In the sense that the alias for 'tactis' should be removed also in 2.7 and 3.2?

----------
title: The email package should defer to the codecs module for	all aliases -> The email package should defer to the codecs module for all aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 17:35:36 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 22 May 2011 15:35:36 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306078536.76.0.778819625706.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file22064/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 17:35:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 15:35:54 +0000
Subject: [issue12138] buggy use of transient_internet() in test_urllibnet
In-Reply-To: <1305995813.93.0.90503071832.issue12138@psf.upfronthosting.co.za>
Message-ID: <E1QOAh7-00007J-1c@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 52b78e07d009 by Antoine Pitrou in branch '3.2':
Issue #12138: fix use of transient_internet() in test_urllibnet
http://hg.python.org/cpython/rev/52b78e07d009

New changeset 18432e8885e0 by Antoine Pitrou in branch 'default':
Issue #12138: fix use of transient_internet() in test_urllibnet
http://hg.python.org/cpython/rev/18432e8885e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12138>
_______________________________________

From report at bugs.python.org  Sun May 22 17:36:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 15:36:16 +0000
Subject: [issue12138] buggy use of transient_internet() in test_urllibnet
In-Reply-To: <1305995813.93.0.90503071832.issue12138@psf.upfronthosting.co.za>
Message-ID: <1306078576.02.0.457167819534.issue12138@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/issue12138>
_______________________________________

From report at bugs.python.org  Sun May 22 17:39:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 15:39:12 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1306078752.66.0.869169313616.issue1441530@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Both patches look ok to me.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Sun May 22 19:19:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 May 2011 17:19:09 +0000
Subject: [issue12145] distutils2 should support README.rst
In-Reply-To: <1306033855.22.0.0348885298579.issue12145@psf.upfronthosting.co.za>
Message-ID: <1306084749.97.0.564122544408.issue12145@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi, thanks for the report.  Distutils is feature frozen, and distutils does not included README{.txt,} by default anymore*.  I don?t know why Tarek changed that.  If he changes his mind, I?d be +1 to your proposal, otherwise it will be rejected.

* The code right now still does, but it?s because of a problem with the repositories, it will get changed again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12145>
_______________________________________

From report at bugs.python.org  Sun May 22 19:19:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 May 2011 17:19:45 +0000
Subject: [issue12143] packaging extension gcc linking fails on Ubuntu Shared
In-Reply-To: <1306020245.1.0.800902261417.issue12143@psf.upfronthosting.co.za>
Message-ID: <1306084785.6.0.644912707775.issue12143@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_distutils failure with --enable-shared

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12143>
_______________________________________

From report at bugs.python.org  Sun May 22 19:21:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 May 2011 17:21:31 +0000
Subject: [issue12135] The spawn function should return stderr.
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1306084891.71.0.523174241442.issue12135@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let?s make one bug for both requests (print whole command line + print stderr), fix it in packaging and discuss if it can be backported to distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12135>
_______________________________________

From report at bugs.python.org  Sun May 22 19:23:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 May 2011 17:23:32 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1306085012.17.0.712090158881.issue12003@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The docs should value readability over conciseness IMHO; the examples here with seven operations in a row are a bit scary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Sun May 22 19:32:14 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 22 May 2011 17:32:14 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1306085534.83.0.159913200366.issue12102@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> that doesn't make me any good

Well - 'can only be better than myself, so i'll take that as yes :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Sun May 22 19:32:18 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 22 May 2011 17:32:18 +0000
Subject: [issue12102] mmap requires file to be synced
In-Reply-To: <1305712564.35.0.453001267253.issue12102@psf.upfronthosting.co.za>
Message-ID: <1306085538.54.0.772564344417.issue12102@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file22020/12102.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12102>
_______________________________________

From report at bugs.python.org  Sun May 22 19:35:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 May 2011 17:35:36 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1306085736.38.0.247344490602.issue12003@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, I'm not sure that the note is necessary at all, but once it's there, it should value *correctness* over conciseness and readability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Sun May 22 20:01:44 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 18:01:44 +0000
Subject: [issue12143] packaging extension gcc linking fails on Ubuntu Shared
In-Reply-To: <1306020245.1.0.800902261417.issue12143@psf.upfronthosting.co.za>
Message-ID: <1306087304.86.0.30040919562.issue12143@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the test David

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12143>
_______________________________________

From report at bugs.python.org  Sun May 22 20:06:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 May 2011 18:06:40 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch causes a segfault while running test_urllib:

$ ./python -m test test_urllib
[1/1] test_urllib
<test.test_urllib.FakeHTTPConnection object at 0xb66b0fbc>
<test.test_urllib.FakeHTTPConnection object at 0xb66b76fc>
<test.test_urllib.FakeHTTPConnection object at 0xb66b7a44>
<test.test_urllib.FakeHTTPConnection object at 0xb66b7f84>
<test.test_urllib.FakeHTTPConnection object at 0xb66c2034>
<test.test_urllib.FakeHTTPConnection object at 0xb66c2034>
Fatal Python error: Segmentation fault

Current thread 0xb77de8d0:
  File "/home/wolf/dev/py/py3k/Lib/http/client.py", line 451 in close
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1119 in do_open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 1166 in http_open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 347 in _call_chain
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 387 in _open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 369 in open
  File "/home/wolf/dev/py/py3k/Lib/urllib/request.py", line 138 in urlopen
  File "/home/wolf/dev/py/py3k/Lib/test/test_urllib.py", line 184 in test_url_fragment
[...]
Segmentation fault

The failure seems to be fairly random, for example if I uncomment the tests at the bottom of test_urllib, the segfault happens only in non-verbose mode.  Also adding a few print()s to debug the issue or making other unrelated changes changes the behavior (e.g. it fails only in verbose mode but not in normal mode).

gdb shows that the failure is in Objects/object.c, at line 981 in the _PyObject_GenericGetAttrWithDict function.  The problem seems to be that 'descr' is invalid and descr->ob_type results in an error:

$ gdb -args ./python -m test test_urllib
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
[...]
Reading symbols from /home/wolf/dev/py/py3k/python...done.
(gdb) run
Starting program: /home/wolf/dev/py/py3k/python -m test test_urllib
[Thread debugging using libthread_db enabled]
[1/1] test_urllib
[New Thread 0xb77e9b70 (LWP 5227)]
<test.test_urllib.FakeHTTPConnection object at 0xb6ec6dfc>

Program received signal SIGSEGV, Segmentation fault.
0x0805c7d8 in _PyObject_GenericGetAttrWithDict (obj=<FakeSocket(io_refs=1) at remote 0xb6ec31e4>, name='close', dict=0x0) at Objects/object.c:982
982             f = descr->ob_type->tp_descr_get;
(gdb) p *(PyUnicodeObject*)descr
$1 = {ob_base = {_ob_next = 0xdbdbdbdb, _ob_prev = 0xdbdbdbdb, ob_refcnt = -606348324, ob_type = 0xdbdbdbdb}, length = -606348325, str = 0xdbdbdbdb, 
  hash = -606348325, state = -606348325, defenc = <unknown at remote 0xdbdbdbdb>}
(gdb) 

FakeHTTPConnection is a subclass of http.client.HTTPConnection, but I also got segfaults in FakeSocket, which is an io.BytesIO subclass.
FWIW I found this while trying to fix ResourceWarnings.  In #12133 I proposed a patch that fixes a ResourceWarnings (included in segfault.diff), and while trying the same approach in urlretrieve (adding a finally: http_conn.close()) and running test_urllib I got the segfault.
Tested on 3.3 only.

----------
components: Interpreter Core
files: segfault.diff
keywords: patch
messages: 136548
nosy: ezio.melotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Segfault in _PyObject_GenericGetAttrWithDict
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file22070/segfault.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Sun May 22 20:09:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 18:09:53 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1306087793.01.0.708548374211.issue12149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This occurs when running the GC and then calling the finalization of an IO object, which temporarily resurrects the object to call its close() method:

#0  0x00007fc20bc1609b in raise () from /lib64/libpthread.so.0
#1  0x00000000005328e7 in faulthandler_fatal_error (signum=11) at ./Modules/faulthandler.c:299
#2  <signal handler called>
#3  0x00000000004190c7 in _PyObject_GenericGetAttrWithDict (obj=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, 
    name='close', dict=0x0) at Objects/object.c:982
#4  0x0000000000419581 in PyObject_GenericGetAttr (obj=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, name=
    'close') at Objects/object.c:1046
#5  0x0000000000418a38 in PyObject_GetAttr (v=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, name='close')
    at Objects/object.c:831
#6  0x00000000004818b4 in PyEval_EvalFrameEx (f=
    Frame 0x7fc2065ee9e8, for file /home/antoine/cpython/default/Lib/http/client.py, line 451, in close (self=<HTTPResponse(fp=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, status='UNKNOWN', will_close='UNKNOWN', chunk_left='UNKNOWN', length='UNKNOWN', headers=None, reason='UNKNOWN', version='UNKNOWN', debuglevel=0, msg=None, chunked='UNKNOWN', _method='GET') at remote 0x7fc20688a220>), throwflag=0) at Python/ceval.c:2268
#7  0x0000000000487a2f in PyEval_EvalCodeEx (_co=<code at remote 0x7fc206992d30>, globals=
    {'BadStatusLine': <type at remote 0x1b21a80>, '__cached__': '/home/antoine/cpython/default/Lib/http/__pycache__/client.cpython-32.pyc', '_UNKNOWN': 'UNKNOWN', 'SWITCHING_PROTOCOLS': 101, 'urlsplit': <function at remote 0x7fc2069d66d8>, 'InvalidURL': <type at remote 0x1b1d490>, 'collections': <module at remote 0x7fc20bef58d0>, 'SERVICE_UNAVAILABLE': 503, 'CREATED': 201, '__file__': '/home/antoine/cpython/default/Lib/http/client.py', 'PROCESSING': 102, 'PRECONDITION_FAILED': 412, 'ssl': <module at remote 0x7fc2068588d0>, 'NOT_ACCEPTABLE': 406, 'HTTPConnection': <type at remote 0x1b01f90>, 'NotConnected': <type at remote 0x1b1c5d0>, 'MULTI_STATUS': 207, 'OK': 200, 'UnknownProtocol': <type at remote 0x1b1d830>, '_CS_REQ_STARTED': 'Request-started', 'email': <module at remote 0x7fc20698c858>, 'NOT_IMPLEMENTED': 501, 'CannotSendRequest': <type at remote 0x1aff730>, 'BAD_GATEWAY': 502, 'CannotSendHeader': <type at remote 0x1affad0>, 'LENGTH_REQUIRED': 411, 'parse_headers': <function at remote 0x7fc20692dec0>, 'HTTP_...(truncated), locals=0x0, args=0x7fc20688a868, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:3301
#8  0x0000000000576a36 in function_call (func=<function at remote 0x7fc2068c9900>, arg=
    (<HTTPResponse(fp=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, status='UNKNOWN', will_close='UNKNOWN', chunk_left='UNKNOWN', length='UNKNOWN', headers=None, reason='UNKNOWN', version='UNKNOWN', debuglevel=0, msg=None, chunked='UNKNOWN', _method='GET') at remote 0x7fc20688a220>,), kw=0x0) at Objects/funcobject.c:629
#9  0x000000000053f975 in PyObject_Call (func=<function at remote 0x7fc2068c9900>, arg=
    (<HTTPResponse(fp=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, status='UNKNOWN', will_close='UNKNOWN', chunk_left='UNKNOWN', length='UNKNOWN', headers=None, reason='UNKNOWN', version='UNKNOWN', debuglevel=0, msg=None, chunked='UNKNOWN', _method='GET') at remote 0x7fc20688a220>,), kw=0x0) at Objects/abstract.c:2149
#10 0x000000000055c1a1 in method_call (func=<function at remote 0x7fc2068c9900>, arg=
    (<HTTPResponse(fp=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, status='UNKNOWN', will_close='UNKNOWN', chunk_left='UNKNOWN', length='UNKNOWN', headers=None, reason='UNKNOWN', version='UNKNOWN', debuglevel=0, msg=None, chunked='UNKNOWN', _method='GET') at remote 0x7fc20688a220>,), kw=0x0) at Objects/classobject.c:319
#11 0x000000000053f975 in PyObject_Call (func=<method at remote 0x7fc20686aba0>, arg=(), kw=0x0)
    at Objects/abstract.c:2149
#12 0x000000000054054c in PyObject_CallMethodObjArgs (callable=<method at remote 0x7fc20686aba0>, name='close')
    at Objects/abstract.c:2350
#13 0x0000000000514f2f in _PyIOBase_finalize (self=
    <HTTPResponse(fp=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, status='UNKNOWN', will_close='UNKNOWN', chunk_left='UNKNOWN', length='UNKNOWN', headers=None, reason='UNKNOWN', version='UNKNOWN', debuglevel=0, msg=None, chunked='UNKNOWN', _method='GET') at remote 0x7fc20688a220>) at ./Modules/_io/iobase.c:222
#14 0x0000000000515143 in iobase_dealloc (self=0x7fc20688a220) at ./Modules/_io/iobase.c:285
#15 0x000000000042fc54 in subtype_dealloc (self=
    <HTTPResponse(fp=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, status='UNKNOWN', will_close='UNKNOWN', chunk_left='UNKNOWN', length='UNKNOWN', headers=None, reason='UNKNOWN', version='UNKNOWN', debuglevel=0, msg=None, chunked='UNKNOWN', _method='GET') at remote 0x7fc20688a220>) at Objects/typeobject.c:968
#16 0x000000000041acb1 in _Py_Dealloc (op=
    <HTTPResponse(fp=<FakeSocket(io_refs=1) at remote 0x7fc2069d8190>, status='UNKNOWN', will_close='UNKNOWN', chunk_left='UNKNOWN', length='UNKNOWN', headers=None, reason='UNKNOWN', version='UNKNOWN', debuglevel=0, msg=None, chunked='UNKNOWN', _method='GET') at remote 0x7fc20688a220>) at Objects/object.c:1693
#17 0x0000000000572b04 in frame_dealloc (f=
    Frame 0x1b6b890, for file /home/antoine/cpython/default/Lib/http/client.py, line 1046, in getresponse ())
#18 0x000000000041acb1 in _Py_Dealloc (op=
    Frame 0x1b6b890, for file /home/antoine/cpython/default/Lib/http/client.py, line 1046, in getresponse ())
    at Objects/object.c:1693
#19 0x00000000004cb7a6 in tb_dealloc (tb=0x7fc2068693a8) at Python/traceback.c:50
#20 0x000000000041acb1 in _Py_Dealloc (op=<traceback at remote 0x7fc2068693a8>) at Objects/object.c:1693
#21 0x00000000004cb72d in tb_dealloc (tb=0x7fc2068691c8) at Python/traceback.c:49
#22 0x000000000041acb1 in _Py_Dealloc (op=<traceback at remote 0x7fc2068691c8>) at Objects/object.c:1693
#23 0x00000000005650af in BaseException_clear (self=0x7fc2069ee960) at Objects/exceptions.c:59
#24 0x000000000056524f in BaseException_dealloc (self=0x7fc2069ee960) at Objects/exceptions.c:69
#25 0x000000000042fc54 in subtype_dealloc (self=<BadStatusLine at remote 0x7fc2069ee960>)
    at Objects/typeobject.c:968
#26 0x000000000041acb1 in _Py_Dealloc (op=<BadStatusLine at remote 0x7fc2069ee960>) at Objects/object.c:1693
#27 0x00000000005651c1 in BaseException_clear (self=0x7fc2069f5990) at Objects/exceptions.c:61
#28 0x00000000005666fa in EnvironmentError_clear (self=0x7fc2069f5990) at Objects/exceptions.c:617
#29 0x0000000000566783 in EnvironmentError_dealloc (self=0x7fc2069f5990) at Objects/exceptions.c:624
#30 0x000000000042fc54 in subtype_dealloc (self=<URLError at remote 0x7fc2069f5990>) at Objects/typeobject.c:968
#31 0x000000000041acb1 in _Py_Dealloc (op=<URLError at remote 0x7fc2069f5990>) at Objects/object.c:1693
#32 0x000000000058e04e in PyDict_Clear (op={}) at Objects/dictobject.c:926
#33 0x0000000000591042 in dict_tp_clear (op={}) at Objects/dictobject.c:1928
#34 0x00000000004da4da in delete_garbage (collectable=0x7fff7ccb0060, old=0x83f680) at Modules/gcmodule.c:739
#35 0x00000000004daa0c in collect (generation=2) at Modules/gcmodule.c:897
#36 0x00000000004dad54 in gc_collect (self=<module at remote 0x7fc20891d510>, args=(), kws=0x0)
    at Modules/gcmodule.c:1034

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Sun May 22 20:12:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 May 2011 18:12:26 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306087946.52.0.618021205144.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

euc_jp and euc_kr seem to be backward (that is, codecs translates them to the _ version, instead of translating the _ version to the - version).  I worry that there might be other deviations from the standard email names.  I would suggest we pull the list of preferred MIME names from the IANA charset registry and make a test out of them in the email package.  If changing the name returned by codecs is determined to not be acceptable, then those entries will need to remain in the charset module ALIASES table and the codecs-check logic adjusted accordingly.

Unfortunately the IANA registry does not list MIME names for all of the charsets in common use, and the canonical names are not always the ones commonly used in email.  Hopefully the codecs registry is using the most common name for those, and hopefully if there are differences it won't break any user code, since any reasonable email code should be coping with the aliases in any case.

Ezio, if you want to steal this one from me, that's fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 20:16:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 May 2011 18:16:58 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306088218.34.0.823705251641.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Must have misread.  Looks like all the common charsets do have MIME entries in the IANA table.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 20:18:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 May 2011 18:18:51 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1306088331.19.0.791837208794.issue1674555@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The advantage of an environment variable is that it is by default inherited by subprocesses.

(These patches no longer apply cleanly. I will create updated patches.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674555>
_______________________________________

From report at bugs.python.org  Sun May 22 20:19:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 May 2011 18:19:59 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306088399.57.0.249552213889.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On second thought the resolution order ought to be swapped anyway: if the user has added an ALIAS, they are going to want that used, not the one from codecs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Sun May 22 20:22:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 18:22:20 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1306088540.88.0.650767023481.issue12149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a quick script to reproduce. It seems that the type of the object has to be caught in a reference cycle for this to happen: apparently the descriptors start being deallocated but the method cache isn't updated yet (?).

----------
nosy: +amaury.forgeotdarc, benjamin.peterson
versions: +Python 3.1
Added file: http://bugs.python.org/file22071/dying.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Sun May 22 20:24:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2011 18:24:01 +0000
Subject: [issue12146] Possible bug in 're' documentation example
In-Reply-To: <1306035815.56.0.741079955993.issue12146@psf.upfronthosting.co.za>
Message-ID: <1306088641.04.0.194987957919.issue12146@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I wrote the recipe and wanted to follow any actions related to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12146>
_______________________________________

From report at bugs.python.org  Sun May 22 20:24:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 18:24:09 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1306088649.1.0.183571638145.issue12149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ezio, in the meantime, you can simply put the FakeSocket declaration at the top level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12149>
_______________________________________

From report at bugs.python.org  Sun May 22 20:29:56 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 18:29:56 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1306088996.36.0.971496063322.issue10126@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am trying to fix this by backporting the distutils fix, but --enabled-share does not work for me ?!

$ make distclean && ./configure --enable-shared --with-pydebug && make
$ ./python
libpython3.3dm.so.1.0: cannot open shared object file: No such file or directory

The so file is present in the srcdir though.

Investigating...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sun May 22 20:30:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 18:30:44 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1306089044.47.0.286593338835.issue10126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Tarek, you must use LD_LIBRARY_PATH.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sun May 22 20:31:36 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 May 2011 18:31:36 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1306089096.56.0.692271867819.issue10801@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

These changes cause test failure on 3.1 branch when verbose mode is disabled:

# python3.1 -m test.regrtest test_zipfile
test_zipfile
test test_zipfile produced unexpected output:
**********************************************************************
*** line 2 of actual output doesn't appear in expected output after line 1:
+ /usr/lib64/python3.1/test/zip_cp437_header.zip
**********************************************************************
1 test failed:
    test_zipfile

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Sun May 22 20:41:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 18:41:19 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <E1QODaX-0003ON-Va@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f1c544245eab by Charles-Fran?ois Natali in branch 'default':
Issue #12105: Add O_CLOEXEC to the os module.
http://hg.python.org/cpython/rev/f1c544245eab

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 20:45:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 22 May 2011 18:45:09 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306089909.72.0.307105260594.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I've committed the patch to 3.3.
Since the documentation aspect is traced in Issue #12103, I'm closing this issue.
????, thanks for reporting this!

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 21:13:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 19:13:41 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306091621.32.0.409787248038.issue12105@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And apparently some buildbot doesn't like it:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/57/

======================================================================
FAIL: test_oscloexec (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_posix.py", line 315, in test_oscloexec
    self.assertTrue(fcntl.fcntl(fd, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
AssertionError: 0 is not true

----------
assignee:  -> charles-francois.natali
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 21:22:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 19:22:15 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <E1QOEE9-00060Y-JX@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3d822e1ca930 by Tarek Ziade in branch 'default':
Issue 10126 - backported distutils fix for the enable-share mode into packaging
http://hg.python.org/cpython/rev/3d822e1ca930

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sun May 22 21:23:16 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 19:23:16 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1306092196.39.0.783674057975.issue10126@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Fixed in packaging. It seems that all fronts are OK, so closing this

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sun May 22 21:44:49 2011
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 22 May 2011 19:44:49 +0000
Subject: [issue12149] Segfault in _PyObject_GenericGetAttrWithDict
In-Reply-To: <1306087600.02.0.632282933103.issue12149@psf.upfronthosting.co.za>
Message-ID: <1306093489.67.0.0769454561875.issue12149@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/issue12149>
_______________________________________

From report at bugs.python.org  Sun May 22 22:04:44 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 20:04:44 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1306094684.79.0.18456783017.issue12132@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sun May 22 22:10:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 20:10:30 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <E1QOEyr-0000ij-6b@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1ba12ac770e0 by Tarek Ziade in branch 'default':
Issue 12132 - skip the test_buil_ext test if the xx module is not found
http://hg.python.org/cpython/rev/1ba12ac770e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sun May 22 22:11:18 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 20:11:18 +0000
Subject: [issue12132] test_packaging failures when run with -j
In-Reply-To: <1305974571.03.0.668055896278.issue12132@psf.upfronthosting.co.za>
Message-ID: <1306095078.71.0.880759665558.issue12132@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12132>
_______________________________________

From report at bugs.python.org  Sun May 22 22:13:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 20:13:13 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <E1QOF1T-0000oT-SR@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9ef8fc5454cb by Victor Stinner in branch '3.1':
Issue #10801: Remove a debug print() from test_zipfile
http://hg.python.org/cpython/rev/9ef8fc5454cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Sun May 22 22:13:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 20:13:48 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1306095228.87.0.704720201307.issue10801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> These changes cause test failure on 3.1 branch when verbose mode is disabled

What a shame! I commited a debug "print()":
    1.39 +        print(fname)

It should be fixed by my last commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Sun May 22 22:15:01 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 20:15:01 +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: <1306095301.02.0.472649314095.issue12141@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

@ned: right. done, and fixes issue12132

----------
assignee: pitrou -> tarek
components: +Library (Lib)
title: --multiprocessing fails with packaging.tests.test_command_build_ext -> sysconfig.get_config_vars('srcdir') fails in specific cases
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/issue12141>
_______________________________________

From report at bugs.python.org  Sun May 22 22:15:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 20:15:15 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306095315.28.0.0625648353349.issue5715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Patch looks fine to me. Is it easily testable?

test_subprocess has some tests checking "cloexec": test_pipe_cloexec() and test_pipe_cloexec_real_tools(). You may reuse some code from these tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Sun May 22 22:19:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 20:19:07 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1306076838.86.0.998398194266.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306095543.3801.2.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> One moment -- adding a new value to the os module looks like a new
> feature to me.  Is there any convincing reason why this needs to go to
> 3.2?  (And it most definitely shouldn't go to 3.1.)

Python doesn't suppose atomic open+CLOEXEC anymore, I consider this as a
regression from Python 2 (which support open("re") with the GNU libc).
Because the patch is simple, I think that it can go in 3.1 and 3.2. Am I
wrong? But... it tooks some years until someone noticed this regression.

Can we add new features to old releases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 22:24:56 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 22 May 2011 20:24:56 +0000
Subject: [issue12150] test_sysconfig fails on solaris
In-Reply-To: <1306095896.24.0.236331245159.issue12150@psf.upfronthosting.co.za>
Message-ID: <1306095896.24.0.236331245159.issue12150@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

======================================================================
ERROR: test_get_path (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sysconfig.py", line 110, in test_get_path
    res = get_path(name, scheme)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'stdlib'

======================================================================
ERROR: test_user_similar (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sysconfig.py", line 281, in test_user_similar
    global_path = get_path(name, 'posix_prefix')
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'stdlib'

----------
assignee: tarek
components: Library (Lib)
messages: 136571
nosy: tarek
priority: normal
severity: normal
status: open
title: test_sysconfig fails on solaris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12150>
_______________________________________

From report at bugs.python.org  Sun May 22 22:25:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 May 2011 20:25:24 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1306095543.3801.2.camel@marge>
Message-ID: <1306095916.3535.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Python doesn't suppose atomic open+CLOEXEC anymore, I consider this as a
> regression from Python 2 (which support open("re") with the GNU libc).

It has never been documented (nor supported) so, no, I wouldn't consider
it a regression.

> But... it tooks some years until someone noticed this regression.

Which means it's certainly unimportant.

> Can we add new features to old releases?

Well, you already know the answer, don't you? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 22:37:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 22 May 2011 20:37:10 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306096630.88.0.538255784754.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> And apparently some buildbot doesn't like it

Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1 little-endian

O_CLOEXEC support was added to Linux 2.6.23: this means that the libc defines it while the kernel doesn't support it (it's probably defined as 0).
I could either add some voodoo configure checks to ensure that O_CLOEXEC is indeed supported, or just skip the test on Linux kernels older than 2.6.23. I prefer the later option, it's much simpler and less error-prone. Sure, it will make O_CLOEXEC available while the kernel doesn't support it on some configurations, but since it's a libc issue...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Sun May 22 22:59:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 May 2011 20:59:10 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1306097950.99.0.678400368697.issue12003@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given that the note is already gone* as obsolete in 3.x, I think a minimal maintenance fix for correctness should be fine for 2.7.

* It is replaced, in essence, by "Ranges containing absolute values larger than sys.maxsize are permitted but some features (such as len()) will raise OverflowError."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Sun May 22 23:35:43 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 22 May 2011 21:35:43 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1306100143.54.0.569132870963.issue11149@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Can someone please review this patch? test_list fails with clang without this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11149>
_______________________________________

From report at bugs.python.org  Mon May 23 01:16:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 23:16:03 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_logging does sometimes fail.

A recent example on Windows XP:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4645/steps/test/logs/stdio

test test_logging failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_logging.py", line 3599, in test_rollover
    self.assertTrue(found, msg=msg)
AssertionError: False is not true : No rotated files found, went back 300 seconds

----------
messages: 136576
nosy: haypo, vinay.sajip
priority: normal
severity: normal
status: open
title: test_logging fails sometimes
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 23 01:17:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2011 23:17:22 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <E1QOHth-00030Q-2X@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 54ffc01b6cc2 by Victor Stinner in branch 'default':
Issue #12151: test_logging writes debug messages to stderr, not stdout
http://hg.python.org/cpython/rev/54ffc01b6cc2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 23 01:31:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2011 23:31:59 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1306107119.02.0.0341486227949.issue12113@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I cannot reproduce the problem: "python -m test test_packaging test_packaging". I suppose that it was fixed by tarek.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Mon May 23 02:05:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 00:05:05 +0000
Subject: [issue12121] test_packaging failure when ssl is not available
In-Reply-To: <1305822178.04.0.171095491628.issue12121@psf.upfronthosting.co.za>
Message-ID: <1306109105.0.0.0922093098963.issue12121@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like Tarek fixed this bug because I'm unable to reproduce it.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12121>
_______________________________________

From report at bugs.python.org  Mon May 23 02:14:11 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 May 2011 00:14:11 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1306109651.95.0.348920352844.issue12144@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/issue12144>
_______________________________________

From report at bugs.python.org  Mon May 23 02:16:22 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 May 2011 00:16:22 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1306109782.85.0.559859036634.issue12144@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Could you possibly test the bug in Python 2.7, 3.1, 3.2 and current 3.3 branch?.

Python 2.6 is open for security fixes only, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Mon May 23 02:19:48 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 May 2011 00:19:48 +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: <1306109988.09.0.131805131866.issue12147@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/issue12147>
_______________________________________

From report at bugs.python.org  Mon May 23 02:32:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 00:32:15 +0000
Subject: [issue12150] test_sysconfig fails on solaris
In-Reply-To: <1306095896.24.0.236331245159.issue12150@psf.upfronthosting.co.za>
Message-ID: <1306110735.88.0.345364886156.issue12150@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Duplicate of #12125.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12150>
_______________________________________

From report at bugs.python.org  Mon May 23 02:32:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 00:32:36 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1306110756.62.0.805985306386.issue12125@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Issue #12150 has been marked as a duplicate of this issue:

======================================================================
ERROR: test_get_path (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sysconfig.py", line 110, in test_get_path
    res = get_path(name, scheme)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'stdlib'

======================================================================
ERROR: test_user_similar (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/test/test_sysconfig.py", line 281, in test_user_similar
    global_path = get_path(name, 'posix_prefix')
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/sysconfig.py", line 436, in get_path
    return get_paths(scheme, vars, expand)[name]
KeyError: 'stdlib'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12125>
_______________________________________

From report at bugs.python.org  Mon May 23 02:47:21 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 May 2011 00:47:21 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1306111641.06.0.620181253414.issue12125@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/issue12125>
_______________________________________

From report at bugs.python.org  Mon May 23 04:52:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2011 02:52:27 +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: <1306119147.18.0.773278489271.issue12147@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the patch.  Adding support for this is a good idea.  There could be a question about whether this constitutes a bug fix or a feature; I'll canvass some other devs and see if we have a consensus on it.

It may take me a bit to find time to do a detailed review, but in broad outline the patch looks sensible and has all the requisite parts (thanks!).

----------
nosy: +r.david.murray
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12147>
_______________________________________

From report at bugs.python.org  Mon May 23 04:52:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2011 02:52:42 +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: <1306119162.35.0.960698346281.issue12147@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/issue12147>
_______________________________________

From report at bugs.python.org  Mon May 23 05:10:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 03:10:53 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <E1QOLXf-0008L6-Go@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 76e5fe8e21fd by Eli Bendersky in branch '2.7':
Issue 12003: fixing error in xrange alternative sample
http://hg.python.org/cpython/rev/76e5fe8e21fd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Mon May 23 05:11:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 23 May 2011 03:11:30 +0000
Subject: [issue12003] documentation: alternate version of xrange seems to fail.
In-Reply-To: <1304546925.26.0.129100386248.issue12003@psf.upfronthosting.co.za>
Message-ID: <1306120290.98.0.434155813819.issue12003@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Agreed. 
Fix committed & issue closed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12003>
_______________________________________

From report at bugs.python.org  Mon May 23 05:12:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 23 May 2011 03:12:45 +0000
Subject: [issue12126] incorrect select documentation
In-Reply-To: <1305851032.27.0.6340611371.issue12126@psf.upfronthosting.co.za>
Message-ID: <1306120365.81.0.295594612203.issue12126@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Closing this issue, since it specifically refers to the select error which was fixed. Tracking the removal of the sockets howto document can be done elsewhere.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12126>
_______________________________________

From report at bugs.python.org  Mon May 23 06:00:00 2011
From: report at bugs.python.org (Peter Wentworth)
Date: Mon, 23 May 2011 04:00:00 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1306123200.6.0.4857811329.issue6717@psf.upfronthosting.co.za>


Peter Wentworth <p.wentworth at ict.ru.ac.za> added the comment:

I can confirm the crash persists as of Python 3.1.3 on Windows, and would like to add my vote to prioritizing it.  

Without having delved into the code, it seems strange that the rapid stream of events is causing stack overflow / recursion limit problems.

It suggests that tkinter is allowing new event arrivals to interrupt older event handling, so that the older ones remain incomplete as the newer ones pile up on the stack. If this is the case, it is going to lead to long-term instability, and needs attention.

The usual technique is to use a queue to decouple "occurs now" from "handle immediately". (The OS puts the mouse and keyboard events onto window's event queue).  So the mainloop that services the event queue should not start handling a new queued event until the previous handling has completed.

----------
nosy: +Peter.Wentworth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon May 23 06:02:43 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 23 May 2011 04:02:43 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1306123363.31.0.164688469.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Ezio, you're right, there are still a lot of undocumented symbols (functions, classes, globals). I compiled a list of those I could not find in the .rst docs, excluding ones that are only used in regrtest.py itself:

------------------------------------------

get_attribute
record_original_stdout/get_original_stdout
unload
unlink
rmtree
make_legacy_pyc
IPV6_ENABLED
TESTFN_ENCODED
TESTFN_UNENCODABLE
sortdict
check_syntax_error
open_urlresource
CleanImport
DirsOnSysPath
transient_internet
captured_output
captured_stderr
gc_collect
python_is_optimized
set_memlimit
bigmemtest
precisionbigmemtest
bigaddrspacetest
requires_resource
cpython_only
impl_detail
check_impl_detail
no_tracing
refcount_test
modules_setup / modules_cleanup
threading_setup / threading_cleanup
reap_threads
reap_children
swap_attr
swap_item
strip_python_stderr
TestHandler
Matcher
patch

------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Mon May 23 06:54:21 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 23 May 2011 04:54:21 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1306126461.25.0.503813397439.issue9942@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In order to arrive at some resolution of this issue, I'm answering the original question ("Should Python enable a way for folks to inform the OS of MADV_MERGEABLE memory?"). The discussion has shown that the answer is "no"; there are no pages of memory where this would provide any advantage.

Closing as "won't fix". Anybody reopening it should

a) provide a patch with the actual change to be made, and
b) accompany it with a benchmark demonstrating some gain.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Mon May 23 07:23:41 2011
From: report at bugs.python.org (Mark Nottingham)
Date: Mon, 23 May 2011 05:23:41 +0000
Subject: [issue7827] recv_into() argument 1 must be pinned buffer,
	not bytearray
In-Reply-To: <1264989221.02.0.754334241076.issue7827@psf.upfronthosting.co.za>
Message-ID: <1306128221.69.0.61452608881.issue7827@psf.upfronthosting.co.za>


Changes by Mark Nottingham <mnot at mnot.net>:


----------
nosy: +mnot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7827>
_______________________________________

From report at bugs.python.org  Mon May 23 08:28:09 2011
From: report at bugs.python.org (Peter Wentworth)
Date: Mon, 23 May 2011 06:28:09 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1306132089.71.0.422557684761.issue6717@psf.upfronthosting.co.za>


Peter Wentworth <p.wentworth at ict.ru.ac.za> added the comment:

Attached is a crashing program that shows that the event handler is called again before activation of the prior instance has completed.

I also have a second turtle that queues the nested events.  It doesn't crash the system, at least.

Perhaps someone can also explain why the handler doesn't work if I leave out the global declaration.

----------
Added file: http://bugs.python.org/file22072/drag_bug_is_nesting_events.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon May 23 09:49:58 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 23 May 2011 07:49:58 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

when building without an hg repository present, the build fails with:

./Parser/asdl_c.py -h ../Include ../Parser/Python.asdl
Traceback (most recent call last):
  File "../Parser/asdl_c.py", line 1214, in <module>
    main(args[0])
  File "../Parser/asdl_c.py", line 1158, in main
    mod.version = get_file_revision(srcfile)
  File "../Parser/asdl_c.py", line 1142, in get_file_revision
    p = subprocess.Popen(args, stdout=subprocess.PIPE)
  File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1141, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
make: *** [../Include/Python-ast.h] Error 1

----------
components: Build
messages: 136591
nosy: doko
priority: normal
severity: normal
status: open
title: Parser/asdl_c.py relies on mercurial repository revision
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 09:50:31 2011
From: report at bugs.python.org (Peter Wentworth)
Date: Mon, 23 May 2011 07:50:31 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1306137031.78.0.802728751087.issue6717@psf.upfronthosting.co.za>


Changes by Peter Wentworth <p.wentworth at ict.ru.ac.za>:


Removed file: http://bugs.python.org/file22072/drag_bug_is_nesting_events.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon May 23 09:56:27 2011
From: report at bugs.python.org (Peter Wentworth)
Date: Mon, 23 May 2011 07:56:27 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1306137387.72.0.251122462626.issue6717@psf.upfronthosting.co.za>


Peter Wentworth <p.wentworth at ict.ru.ac.za> added the comment:

Oops, I wish I hadn't asked that silly question about the global declaration!

Here is the tweaked file...

----------
Added file: http://bugs.python.org/file22073/drag_bug_is_nesting_events.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Mon May 23 10:11:57 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 08:11:57 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306138317.9.0.283219036638.issue12009@psf.upfronthosting.co.za>


Ruslan Mstoi <rmstoi at gmail.com> added the comment:

Uploading patch updated according to the review comments.

----------
Added file: http://bugs.python.org/file22074/issue12009_patch3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 10:31:36 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 23 May 2011 08:31:36 +0000
Subject: [issue12153] Modules/faulthandler.c exports `stack_overflow' symbol
In-Reply-To: <1306139496.56.0.0926484812562.issue12153@psf.upfronthosting.co.za>
Message-ID: <1306139496.56.0.0926484812562.issue12153@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

the exported symbol should either have a prefix, or defined static.

----------
components: Extension Modules
messages: 136594
nosy: doko
priority: normal
severity: normal
status: open
title: Modules/faulthandler.c exports `stack_overflow' symbol
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12153>
_______________________________________

From report at bugs.python.org  Mon May 23 11:04:11 2011
From: report at bugs.python.org (=?utf-8?q?Gergely_K=C3=A1lm=C3=A1n?=)
Date: Mon, 23 May 2011 09:04:11 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1306026867.06.0.283714694798.issue6560@psf.upfronthosting.co.za>
Message-ID: <4DDA2306.4000805@duodecad.hu>


Gergely K?lm?n <kalman.gergely at duodecad.hu> added the comment:

On 05/22/11 03:14, Brian May wrote:
> Brian May<brian at microcomaustralia.com.au>  added the comment:
>
> What needs to happen to get recvmsg() supported in Python?
>
> recvmsg() is required to get get transparent UDP proxies working under Linux using tproxy, the code needs to run recvmsg() to be able to find out what the original destination address was for the the packet.
>
> Thanks
>
> Brian May
>
> ----------
> nosy: +brian
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue6560>
> _______________________________________

Hello Brian!

It's been a while I had a look at that code. As far as I remember though 
the code is fairly decent not
taking the missing unit tests into account. There are a few todos, and 
also a pretty bad bug that I've fixed
but not committed. The TODOs include better parsing of auxiliary data, 
support for scatter-gather, addressed
messages. If you wish I can send you the latest patch that has the bug 
fixed and applies to 3.2. Do you want
this to be pushed to 3.3?

Gergely Kalman

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon May 23 11:15:31 2011
From: report at bugs.python.org (JJeffries)
Date: Mon, 23 May 2011 09:15:31 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>


New submission from JJeffries <jamesjeffries1 at gmail.com>:

PyDoc currently does not support partial functions. It currently just outputs the following, treating it as a data member instead of a function.

my_partial_function = <functools.partial object>

I think that if the __doc__ it should be treated as a function and the __doc__ read.

----------
components: Library (Lib)
messages: 136596
nosy: JJeffries
priority: normal
severity: normal
status: open
title: PyDoc Partial Functions
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12154>
_______________________________________

From report at bugs.python.org  Mon May 23 11:30:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 09:30:48 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1306143048.47.0.895017051271.issue12151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Victor, you just did what a recent discussion on python-dev strongly recommended not to do: you used ambiguous present tense in your commit message.  ?test_logging writes debug messages to stderr, not stdout? does not say whether it is the buggy behavior (unambiguous example for that: ?test_logging used to write debug messages to stderr, not stdout?) or the new, fixed behavior (?test_logging now writes debug messages to stderr, not stdout?).  You should use unambiguous phrasing like ?make X do Y?, ?fix Y with Z?, ?don?t W when Z?.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 23 11:31:02 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 09:31:02 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306143062.42.0.581975577577.issue12009@psf.upfronthosting.co.za>


Changes by Ruslan Mstoi <rmstoi at gmail.com>:


Added file: http://bugs.python.org/file22075/issue12009_patch4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 11:31:44 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 09:31:44 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306143104.1.0.668020372698.issue12009@psf.upfronthosting.co.za>


Changes by Ruslan Mstoi <rmstoi at gmail.com>:


Removed file: http://bugs.python.org/file22013/issue12009_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 11:31:48 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 09:31:48 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306143108.54.0.428759356012.issue12009@psf.upfronthosting.co.za>


Changes by Ruslan Mstoi <rmstoi at gmail.com>:


Removed file: http://bugs.python.org/file22019/issue12009_patch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 11:31:53 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 09:31:53 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306143113.65.0.150484622825.issue12009@psf.upfronthosting.co.za>


Changes by Ruslan Mstoi <rmstoi at gmail.com>:


Removed file: http://bugs.python.org/file22074/issue12009_patch3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 11:40:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 09:40:15 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306143615.55.0.553208295753.issue12009@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to that last patch, modulo removal of an unnecessary docstring on one test method (IIRC the test runner would display it in verbose mode and that would not be useful output; the test speaks for itself, only a comment with this bug number is maybe missing).  Ruslan, you don?t have to edit the patch, David will do it before commit if he wants to.  Thanks for your contribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 11:55:20 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 09:55:20 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306144520.9.0.770443231352.issue12009@psf.upfronthosting.co.za>


Changes by Ruslan Mstoi <rmstoi at gmail.com>:


Added file: http://bugs.python.org/file22076/issue12009_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 11:55:25 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 09:55:25 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306144525.94.0.592620067954.issue12009@psf.upfronthosting.co.za>


Changes by Ruslan Mstoi <rmstoi at gmail.com>:


Removed file: http://bugs.python.org/file22075/issue12009_patch4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 12:04:09 2011
From: report at bugs.python.org (Ruslan Mstoi)
Date: Mon, 23 May 2011 10:04:09 +0000
Subject: [issue12009] netrc module crashes if netrc file has comment lines
In-Reply-To: <1304601950.35.0.920336944366.issue12009@psf.upfronthosting.co.za>
Message-ID: <1306145049.26.0.550213072895.issue12009@psf.upfronthosting.co.za>


Ruslan Mstoi <rmstoi at gmail.com> added the comment:

Thanks for helping with cleaning up the patch. I already removed that docstring too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12009>
_______________________________________

From report at bugs.python.org  Mon May 23 12:08:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 10:08:19 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306145299.03.0.269127937974.issue12154@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  pydoc recently gained ad-hoc support for named tuples, so it could be improved to treat partial objects as functions.  Would you like to submit a patch?  If so, guidelines are on http://docs.python.org/devguide

----------
nosy: +eric.araujo, rhettinger
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12154>
_______________________________________

From report at bugs.python.org  Mon May 23 12:08:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 10:08:36 +0000
Subject: [issue12153] Modules/faulthandler.c exports `stack_overflow' symbol
In-Reply-To: <1306139496.56.0.0926484812562.issue12153@psf.upfronthosting.co.za>
Message-ID: <1306145316.6.0.0341779071218.issue12153@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> haypo
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12153>
_______________________________________

From report at bugs.python.org  Mon May 23 12:09:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 10:09:23 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306145363.24.0.895777520321.issue12152@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 12:22:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 10:22:31 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The queue doc contains the following example:
------------------
def worker():
    while True:
        item = q.get()
        do_work(item)
        q.task_done()

q = Queue()
for i in range(num_worker_threads):
     t = Thread(target=worker)
     t.daemon = True
     t.start()

for item in source():
    q.put(item)

q.join()       # block until all tasks are done
------------------
http://docs.python.org/library/queue.html

It doesn't define do_work(), num_worker_threads or do_work(), but my concern is that it doesn't stop worker threads.

I consider "t.daemon = True" as an hack to not care about stopping threads.

The example should pass a special value to each worker to stop it. For example:

<worker>

while True:
  job = queue.get()
  if job is None:
     break
  audio.play(*job)
  queue.task_done()

Main thread:

...
threads = []
for i in range(num_worker_threads):
     t = Thread(target=worker)
     threads.append(t)
     t.start()
...
for i in range(num_worker_threads):
     queue.put(None)
queue.join()
for thread in threads:
    thread.join()

----------
assignee: docs at python
components: Documentation
messages: 136601
nosy: docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: queue example doesn't stop worker threads
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Mon May 23 12:24:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 10:24:18 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1306146258.69.0.250886279992.issue12125@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/issue12125>
_______________________________________

From report at bugs.python.org  Mon May 23 12:30:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 10:30:36 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1306146636.3.0.480530844048.issue6727@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Removing 2.6, this is not a security bug.

(OT:
> Could someone please fix support for symlinked packages? It's an
> essential feature during development.
If I correctly guess your use case, you could use a pth file during development.  See the docs.)

----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Mon May 23 12:30:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 10:30:39 +0000
Subject: [issue12153] Modules/faulthandler.c exports `stack_overflow' symbol
In-Reply-To: <1306139496.56.0.0926484812562.issue12153@psf.upfronthosting.co.za>
Message-ID: <E1QOSPF-0005l2-4h@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ad1ea4961ead by Victor Stinner in branch 'default':
Close #12153: faulthandler, mark stack_overflow() as static
http://hg.python.org/cpython/rev/ad1ea4961ead

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12153>
_______________________________________

From report at bugs.python.org  Mon May 23 12:31:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 10:31:18 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1306146678.46.0.0375135506057.issue6727@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, does this bug occur only with symlinked packages or also with one-file modules?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Mon May 23 12:33:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 10:33:14 +0000
Subject: [issue12128] Allow an abc.abstractproperty to be overridden by an
	instance data attribute
In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za>
Message-ID: <1306146794.88.0.785616866722.issue12128@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: Allow `abc.abstractproperty` to be overridden by a data attribute -> Allow an abc.abstractproperty to be overridden by an instance data attribute
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12128>
_______________________________________

From report at bugs.python.org  Mon May 23 12:33:39 2011
From: report at bugs.python.org (Waldemar Kornewald)
Date: Mon, 23 May 2011 10:33:39 +0000
Subject: [issue6727] ImportError when package is symlinked on Windows
In-Reply-To: <1250608383.93.0.471187637916.issue6727@psf.upfronthosting.co.za>
Message-ID: <1306146819.53.0.912744566256.issue6727@psf.upfronthosting.co.za>


Waldemar Kornewald <wkornewald at gmail.com> added the comment:

It was only with symlinked packages/folders. Symlinked files worked correctly for me.

BTW, pth files won't work for our specific use-case (App Engine).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6727>
_______________________________________

From report at bugs.python.org  Mon May 23 12:37:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 10:37:58 +0000
Subject: [issue12156] test_multiprocessing
Message-ID: <1306147078.6.0.687476202649.issue12156@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: haypo
priority: normal
severity: normal
status: open
title: test_multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Mon May 23 12:40:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 10:40:54 +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: <1306147254.92.0.286085135906.issue12156@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1819/steps/test/logs/stdio

[180/355] test_multiprocessing
Timeout (1:00:00)!
Thread 0x28401d00:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 354 in _send
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 382 in _send_bytes
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 216 in send
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/managers.py", line 104 in dispatch
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/managers.py", line 746 in _connect
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/managers.py", line 758 in _callmethod
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/managers.py", line 986 in acquire
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 659 in f
  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 0x28401040:
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 364 in _recv
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 385 in _recv_bytes
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/connection.py", line 260 in recv
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/managers.py", line 762 in _callmethod
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/multiprocessing/managers.py", line 986 in acquire
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 738 in test_notify_all
  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/test/support.py", line 1103 in run
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1191 in _run_suite
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/support.py", line 1217 in run_unittest
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py", line 2164 in test_main
  File "./Lib/test/regrtest.py", line 1048 in runtest_inner
  File "./Lib/test/regrtest.py", line 842 in runtest
  File "./Lib/test/regrtest.py", line 666 in main
  File "./Lib/test/regrtest.py", line 1623 in <module>
program finished with exit code 1
elapsedTime=7790.461967

Note: many other tests fail on this buildbot (because of file permissions?) which looks to be ill.

----------
components: +Library (Lib)
nosy: +charles-francois.natali, pitrou
title: test_multiprocessing -> test_multiprocessing.test_notify_all() timeout (1 hour) on FreeBSD 7.2
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12156>
_______________________________________

From report at bugs.python.org  Mon May 23 12:49:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 May 2011 10:49:17 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1306147757.49.0.54312262847.issue12155@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Mon May 23 12:55:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 10:55:00 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <E1QOSmp-0007ca-18@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bff9265d677d by Victor Stinner in branch 'default':
Issue #12105: test_posix, add the value of O_CLOEXEC in the error message
http://hg.python.org/cpython/rev/bff9265d677d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 12:55:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 10:55:47 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306148147.49.0.474809278195.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> or just skip the test on Linux kernels older than 2.6.23

I like this solution, but I don't know how to test that the kernel doesn't support O_CLOEXEC. My commit bff9265d677d will tell use the value of O_CLOEXEC on the "Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1 little-endian" buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 13:00:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 May 2011 11:00:54 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1306148147.49.0.474809278195.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306148451.3539.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I like this solution, but I don't know how to test that the kernel
> doesn't support O_CLOEXEC. My commit bff9265d677d will tell use the
> value of O_CLOEXEC on the
> "Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1 little-endian" buildbot.

If O_CLOEXEC is a #defined constant in the glibc, it can't be different
from other kernels.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 13:08:02 2011
From: report at bugs.python.org (Philip Drew)
Date: Mon, 23 May 2011 11:08:02 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306148882.31.0.104257209314.issue12140@psf.upfronthosting.co.za>


Philip Drew <pwtdrew at gmail.com> added the comment:

Reinstalling makes no difference- have tried multiple times

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Mon May 23 13:11:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 11:11:08 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306149068.46.0.486595321072.issue5715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, Linux 2.6.27+ has a SOCK_CLOEXEC option: we may use it (but it should be done in another issue). See also #12105.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Mon May 23 13:19:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 11:19:14 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306149554.18.0.103987009697.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Story of O_CLOEXEC in the GNU libc, by Ulrich Drepper: "Secure File Descriptor Handling"
http://udrepper.livejournal.com/20407.html

--

> I could either add some voodoo configure checks to ensure
> that O_CLOEXEC is indeed supported

Hum, if I patch tempfile._mkstemp_inner() to use os.O_CLOEXEC if available, whereas this flag has no effect, the function will be less secure on Linux 2.6.22 (if the GNU libc exposes O_CLOEXEC).

Check O_CLOEXEC is configure is not safe if the host compiling Python uses a different kernel that the host running Python (e.g. think of Linux distro: Python is compiled on a different computer).

We need maybe a flag to indicate that O_CLOEXEC is supported by the running kernel or not. Or maybe a function to check it at least?

--

O_CLOEXEC was added to Ruby and then removed because the flag is sometimes ignored:
http://redmine.ruby-lang.org/issues/1291
http://redmine.ruby-lang.org/projects/ruby-19/repository/revisions/31643

"because boron chkbuild test result says, An old linux kernel ignore O_CLOEXEC silently instead of return an error. It may lead to bring new security risk. So, we have to be pending it until finish to implement proper fallback logic."

--

Read also the discussion about O_CLOEXEC on bugs-findutils mailing list:
"it's not a guarantee that the O_CLOEXEC actually had an effect"

Their patch uses :

static int
fd_is_cloexec (int fd)
{
  const int flags = fcntl (fd, F_GETFD);
  return (flags & FD_CLOEXEC) || (fcntl (fd, F_GETFL) & O_CLOEXEC);
}

static bool
o_cloexec_works (void)
{
  bool result = false;
  int fd = open ("/", O_RDONLY|O_CLOEXEC);
  if (fd >= 0)
    {
      result = fd_is_cloexec (fd);
      close (fd);
    }
  return result;
}

--

Oh, there is also SOCK_CLOEXEC, which may be useful for #5715.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 13:32:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 11:32:37 +0000
Subject: [issue4600] __class__ assignment: new-style? heap? == confusing
In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>
Message-ID: <1306150357.49.0.0313477630367.issue4600@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4600>
_______________________________________

From report at bugs.python.org  Mon May 23 13:32:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 11:32:59 +0000
Subject: [issue4600] __class__ assignment: new-style? heap? == confusing
In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>
Message-ID: <1306150379.87.0.0495950404924.issue4600@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> 
nosy:  -docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4600>
_______________________________________

From report at bugs.python.org  Mon May 23 13:42:46 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Mon, 23 May 2011 11:42:46 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>


New submission from G?k?en Eraslan <gokcen at pardus.org.tr>:

When I use map method Pool object with an empty list parameter and then call close and wait methods, join() method hangs. I think this is not intended.

Code to reproduce the bug is attached. 

PS: A similar issue (using map method with an empty list argument) is reported here[1], but it was about the chunksize parameter and it's resolved.

[1] http://bugs.python.org/issue6433

----------
components: Library (Lib)
files: multi.py
messages: 136613
nosy: G?k?en.Eraslan, jnoller
priority: normal
severity: normal
status: open
title: join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22077/multi.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Mon May 23 13:46:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 May 2011 11:46:44 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1306151204.34.0.615618056023.issue10115@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +charles-francois.natali, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Mon May 23 13:48:58 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 11:48:58 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1306087946.52.0.618021205144.issue8898@psf.upfronthosting.co.za>
Message-ID: <4DDA49A6.1010300@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> euc_jp and euc_kr seem to be backward (that is, codecs translates them to the _ version, instead of translating the _ version to the - version).  I worry that there might be other deviations from the standard email names.  I would suggest we pull the list of preferred MIME names from the IANA charset registry and make a test out of them in the email package.  If changing the name returned by codecs is determined to not be acceptable, then those entries will need to remain in the charset module ALIASES table and the codecs-check logic adjusted accordingly.
> 
> Unfortunately the IANA registry does not list MIME names for all of the charsets in common use, and the canonical names are not always the ones commonly used in email.  Hopefully the codecs registry is using the most common name for those, and hopefully if there are differences it won't break any user code, since any reasonable email code should be coping with the aliases in any case.

The way I understand the patch was that the email package will
start to use the encoding aliases for determining the codec
name instead of its own list. That is: only for decoding the
input data, not for creating a correct MIME encoding name in
output data.

----------
title: The email package should defer to the codecs module for all aliases -> The email package should defer to the codecs module for	all aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Mon May 23 13:50:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 11:50:57 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306151457.43.0.770422598622.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another idea is to write a best-effort function to open a file with CLOEXEC flag:
 * use O_CLOEXEC if available
 * use fcntl(fd, F_SETFD, flags | FD_CLOEXEC) if O_CLOEXEC is missing or was silently ignored by the kernel (by open)

Attached open_cloexec.py is an implementation.

--

Usage of "CLOEXEC" in the Python standard library:

- subprocess: create pipe. use pipe2() or pipe()+fcntl(FD_CLOEXEC)
- test_socket: create a socket. use SOCK_CLOEXEC. The test is skipped if the kernel is Linux < 2.6.28. It has a nice linux_version() which should be moved to the platform module.
- test_posix: check open(O_CLOEXEC).
- test_tempfile: test "cloexec" behaviour using os.spawnl()
- xmlrpclib: use FD_CLOEXEC on the socket

You may also add pipe_cloexec() to os, and socket_cloexec() to socket?

----------
Added file: http://bugs.python.org/file22078/open_cloexec.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 13:52:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 11:52:32 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306151552.4.0.978827203205.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> My commit bff9265d677d will tell use the value of O_CLOEXEC on the
> "Linux-2.6.22-vs2.2.0.7-gentoo-..." buildbot.

Here you have:
"AssertionError: 0 is not true : CLOEXEC flag not set (O_CLOEXEC=0x80000)"

It's the same value on my Debian Sid. So we cannot test O_CLOEXEC value, we have to check the kernel version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 13:59:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 May 2011 11:59:49 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306151989.63.0.931069980695.issue8796@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If there are use cases of Stream{Reader,Writer} which are not covered by TextIOWrapper, it would be nice to know so that we can improve TextIOWrapper. After all, there should be one obvious way to do it ;)

By the way, something interesting (probably unintended):

>>> codecs.open("LICENSE", "r")
<_io.TextIOWrapper name='LICENSE' mode='r' encoding='UTF-8'>
>>> codecs.open("LICENSE", "r", encoding="utf-8")
<codecs.StreamReaderWriter object at 0x7f71846ac840>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon May 23 14:06:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 May 2011 12:06:40 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306152400.31.0.957876973426.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The real issue is that the libc defines O_CLOEXEC, but kernels prior to 2.6.23 don't support it: instead of returning EINVAL, the socket syscall silently ignores the flag (don't know why I made the comment about this flag being defined to 0...).
IMHO this is really a distribution packaging bug (kernel/libc mismatch), and a quite serious one.
I don't think we should be fixing this in Python, but that we should merely skip this test on kernels older than 2.6.23.
People should complain to their distributions vendors instead (I tested this on RHEL4, RHEL6 and Debian Squeeze without problem).

I personally don't like the idea of a best-effort O_CLOEXEC implementation: providing a O_CLOEXEC flag which is not atomic feels really wrong to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 14:11:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 12:11:27 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306152687.79.0.897007292778.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The real issue is that the libc defines O_CLOEXEC, but kernels prior 
> to 2.6.23 don't support it: instead of returning EINVAL, the socket
> syscall silently ignores the flag (don't know why I made the comment
> about this flag being defined to 0...).

This is a kernel bug, not a bug in the GNU libc (ask Ulrich if you are not sure ;-)). An host can have multiple kernel versions (and choose at boot time using GRUB/LILO/...), but it has usually only one C library. You cannot change the version of the libc depending on the kernel.

If you really want to fix this problem, you will have to patch kernel < 2.6.23. Good luck!

Or we can workaround kernel bugs providing a documentation and/or functions for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 14:14:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 May 2011 12:14:22 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306152862.21.0.798153120568.issue5715@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Oh, Linux 2.6.27+ has a SOCK_CLOEXEC option:

It's not exactly the same thing.
We want to close the socket right after fork, not wait until exec (in the OP case there was no exec).

> Patch looks fine to me. Is it easily testable?

Easily, no.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Mon May 23 14:25:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 12:25:27 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Sometimes, we need to know the version of the Linux kernel. Recent examples: test if SOCK_CLOEXEC or O_CLOEXEC are supported by the kernel or not. Linux < 2.6.23 *silently* ignores O_CLOEXEC flag of open().

linux_version() is already implemented in test_socket, but it looks like test_posix does also need it.

Attached patch adds platform.linux_version(). It returns (a, b, c) (integers) or None (if not Linux).

It raises an error if the version string cannot be parsed.

----------
components: Library (Lib)
files: platform_linux_version.patch
keywords: patch
messages: 136621
nosy: charles-francois.natali, haypo, lemburg, pitrou
priority: normal
severity: normal
status: open
title: platform: add linux_version()
versions: Python 3.3
Added file: http://bugs.python.org/file22079/platform_linux_version.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 14:25:40 2011
From: report at bugs.python.org (Tim Golden)
Date: Mon, 23 May 2011 12:25:40 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306153540.84.0.418067741589.issue12140@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

What happens if you try "python -S" (capital S)? In principle this should bypass the need to load site.py. Even if that works we still have a problem to solve, but at least it might narrow things down.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Mon May 23 14:26:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 12:26:11 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306153571.98.0.471258382905.issue12105@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> test_socket: ...has a nice linux_version() which should be moved to 
> the platform module

I created the issue #12158 for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 14:27:08 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 May 2011 12:27:08 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306153628.61.0.335243341535.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This is a kernel bug, not a bug in the GNU libc (ask Ulrich if you are not sure ;-)).

Kernels prior to 2.6.23 didn't know about the O_CLOEXEC flag: to catch this kind of problem, every syscall would have to check every bit when it's passed a combination of flags. This would be clumsy, error-prone and slow.
It's not a libc bug either.
The problem is really a distribution issue: using a libc defining a flag unsupported by the kernel is really calling for trouble.

> An host can have multiple kernel versions (and choose at boot time using GRUB/LILO/...)

It's possible, but it's definitely a bad idea, because of such API mismatch. For example nothing prevents a syscall from being removed/modified from one kernel version to another. If your libc doesn't follow, you're up for trouble.
Try using futexes with a kernel not supporting them :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 14:27:17 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 23 May 2011 12:27:17 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <1306153637.61.0.724154221312.issue12158@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/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 15:02:57 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 13:02:57 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <4DDA5AFC.6000005@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> Sometimes, we need to know the version of the Linux kernel. Recent examples: test if SOCK_CLOEXEC or O_CLOEXEC are supported by the kernel or not. Linux < 2.6.23 *silently* ignores O_CLOEXEC flag of open().
> 
> linux_version() is already implemented in test_socket, but it looks like test_posix does also need it.
> 
> Attached patch adds platform.linux_version(). It returns (a, b, c) (integers) or None (if not Linux).
> 
> It raises an error if the version string cannot be parsed.

The APIs in platform generally try not to raise errors, but instead
return a default value you pass in as parameter in case the
data cannot be fetched from the system.

The returned value should be a version string in a fixed
format, not a tuple. I'd suggest to use _norm_version()
for this.

Please also check whether this works on a few Linux systems.

I've checked it on openSUSE, Ubuntu.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-06-20: EuroPython 2011, Florence, Italy               28 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 15:06:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 13:06:07 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <1306155967.28.0.782949914698.issue12158@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The returned value should be a version string in a fixed format,
> not a tuple. I'd suggest to use _norm_version() for this.

How do you compare version strings? I prefer tuples, as sys.version_info, because the comparaison is more natural:

>>> '2.6.9' > '2.6.20'
True
>>> (2, 6, 9) > (2, 6, 20)
False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 15:11:27 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 13:11:27 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306155967.28.0.782949914698.issue12158@psf.upfronthosting.co.za>
Message-ID: <4DDA5CFB.6090804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> The returned value should be a version string in a fixed format,
>> not a tuple. I'd suggest to use _norm_version() for this.
> 
> How do you compare version strings? I prefer tuples, as sys.version_info, because the comparaison is more natural:
> 
>>>> '2.6.9' > '2.6.20'
> True
>>>> (2, 6, 9) > (2, 6, 20)
> False

The APIs are mostly used for creating textual representations
of system information, hence the use of strings.

You can add an additional linux_version_info() API if you want to
have tuples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 15:15:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2011 13:15:10 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306156510.75.0.523160770049.issue12152@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

asdl_c.py should not be run during a non-checkout build, since the files it builds should already have been (re)built and checked in by the time a release is rolled.  IIUC The release building script is supposed to ensure the timestamps of the files are such that it won't be called.  What source are you doing the non-checkout build from?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 15:15:47 2011
From: report at bugs.python.org (Sye van der Veen)
Date: Mon, 23 May 2011 13:15:47 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1306156547.05.0.782914193562.issue10224@psf.upfronthosting.co.za>


Sye van der Veen <syeberman at rogers.com> added the comment:

I ran smack into this while setting up my Doc build for the first time.  In trying to fix my build problems, it took me about an hour to find that this was a known issue.

I've attached a patch to warn others of the issue, in the documentation and the build itself.  Also, I've updated the version of Sphinx in building.rst, and made a note reminding others to do the same. I've only tested this patch on Windows 7.

----------
keywords: +patch
nosy: +syeberman
Added file: http://bugs.python.org/file22080/Issue10224Warnings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Mon May 23 15:18:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2011 13:18:12 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1306156692.48.0.892271347511.issue12151@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's another (unrelated?) failure:

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/173/steps/test/logs/stdio

[ 43/355] test_logging
----------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 582, in process_request_thread
    self.finish_request(request, client_address)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 641, in __init__
    self.finish()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socketserver.py", line 713, in finish
    self.socket.sendto(self.wfile.getvalue(), self.client_address)
socket.error: [Errno 9] Bad file descriptor
test test_logging failed -- multiple errors occurred; run in verbose mode for details

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 23 15:21:58 2011
From: report at bugs.python.org (Nir Aides)
Date: Mon, 23 May 2011 13:21:58 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306156918.87.0.095963073827.issue1625@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


----------
assignee: niemeyer -> nirai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon May 23 15:25:22 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 23 May 2011 13:25:22 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306157122.97.0.964681928093.issue12152@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Indeed, Include/Python-ast.c and Python/Python-ast.c should be touched to avoid this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 15:27:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 13:27:35 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <1306157255.86.0.897299228515.issue12158@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Use "%s.%s.%s" % linux_version() if you would like to format the version. The format is well defined. (You should only do that under Linux.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 15:30:13 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 13:30:13 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306157255.86.0.897299228515.issue12158@psf.upfronthosting.co.za>
Message-ID: <4DDA6161.5090604@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Use "%s.%s.%s" % linux_version() if you would like to format the version. The format is well defined. (You should only do that under Linux.)

No, please follow the API conventions in that module and use a string.

You can then use linux_version().split('.') in code that want to
do version comparisons.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-06-20: EuroPython 2011, Florence, Italy               28 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 15:32:11 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 23 May 2011 13:32:11 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306157531.75.0.885319053759.issue12152@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

I'm building a snapshot package on a buildd, where a checkout is used (without the .hg directory). buildds don't have access to the network, and I don't want to package the .hg directory. So I assume I have to create a "release" tarball on my own, and build from that one. iirc I didn't see this behaviour with python3.2 when building pre alpha snapshot packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 15:36:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 23 May 2011 13:36:26 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306157786.98.0.326648847177.issue12152@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It's true that Python use to be the only dependency for asdl_c.py, but now Mercurial is, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 15:43:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2011 13:43:47 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306158227.38.0.145895192713.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it turns out that back when I opened this issue I misunderstood what the ALIASES table was used for.  it *is* used before doing a codecs lookup, but it is also used to convert whatever charset name the programmer specifies into the standard MIME name for the codec when generating emails.

Clearly the email module needs to base its transformation on the IANA table.  I think the ideal would be to have a program that pulls the IANA table and generates the ALIASES table.  On the other hand, codecs should already have all of those aliases (this theoretical program could be used to ensure that), so another alternative is to use codecs to look up the "python canonical" name for the charset, and have the email ALIASES table just map the ones where that isn't the preferred MIME name into the MIME name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Mon May 23 15:57:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 13:57:45 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1306159065.28.0.119945332401.issue10224@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t see how the comment ?As such, you will need to specify PYTHON explicitly? logically follows from the fact that Python 2.x is required.  IMO, building the docs require Python 2.x, so you?ll need a ?python? executable on your PATH that is 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Mon May 23 15:59:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 May 2011 13:59:09 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <4DDA6161.5090604@egenix.com>
Message-ID: <BANLkTi=5NZYCiYsBqxKyOAZeUzrrd9QGSA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Do we really need to expose a such Linux-centric and sparingly used
function to the platform module?
Since it's needed by several tests, why not add it to Lib/test/support.py?
That way, we could also make it return a tuple without breaking any
existing convention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 16:00:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:00:18 +0000
Subject: [issue11729] libffi assembler relocation check is not robust,
	fails with clang
In-Reply-To: <1301575120.29.0.707250693117.issue11729@psf.upfronthosting.co.za>
Message-ID: <1306159218.87.0.245420525353.issue11729@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See also #12081.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11729>
_______________________________________

From report at bugs.python.org  Mon May 23 16:04:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:04:56 +0000
Subject: [issue11178] Running tests inside a package by module name fails
In-Reply-To: <1297369148.53.0.82343889297.issue11178@psf.upfronthosting.co.za>
Message-ID: <1306159496.98.0.487390055569.issue11178@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/issue11178>
_______________________________________

From report at bugs.python.org  Mon May 23 16:09:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:09:45 +0000
Subject: [issue12022] AttributeError should report the same details when
	raised by lookup_special() as when raised in the REPL
In-Reply-To: <1304712442.84.0.0469522790948.issue12022@psf.upfronthosting.co.za>
Message-ID: <1306159785.5.0.952118645579.issue12022@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> hasattr(transaction, '__exit__')

http://docs.python.org/dev/reference/datamodel#special-method-names explains that magic methods are looked up on the class, not on the instances.  There?s a lot of code out there that erroneously checks for __len__ or __call__ on instances, and this is the second time to my knowledge that a project abused a module-level __enter__ function.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12022>
_______________________________________

From report at bugs.python.org  Mon May 23 16:15:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:15:08 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1306160108.62.0.9577988039.issue12134@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I believe Antoine is saying ?works as intended?, i.e. not a bug.  I?m not sure it?s worth a doc change.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Mon May 23 16:16:28 2011
From: report at bugs.python.org (JJeffries)
Date: Mon, 23 May 2011 14:16:28 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306160188.29.0.669154394155.issue12154@psf.upfronthosting.co.za>


JJeffries <jamesjeffries1 at gmail.com> added the comment:

I have written and tested a patch based on 2.7.1 src distribution (only src I have access to at work). I will get the latest code from the repository and test against that later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12154>
_______________________________________

From report at bugs.python.org  Mon May 23 16:22:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:22:34 +0000
Subject: [issue12148] Clarify "or-ing together" doctest option flags
In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>
Message-ID: <1306160554.36.0.693145042449.issue12148@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As a non-native speaker, I found constructs such as ?OR-ed? or ?syncing? a bit non-obvious when I started reading docs.  +1 on adding ?bitwise?, +1 on changing to ?combined with the | operator?.  (Yes, this is an or-ed vote.)

----------
nosy: +eric.araujo
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12148>
_______________________________________

From report at bugs.python.org  Mon May 23 16:24:02 2011
From: report at bugs.python.org (Peter Fankhaenel)
Date: Mon, 23 May 2011 14:24:02 +0000
Subject: [issue12159] Integer Overflow in __len__
In-Reply-To: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>
Message-ID: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>


New submission from Peter Fankhaenel <pit007am at googlemail.com>:

An OverflowError is emitted in case the return value of __len__
exceeds 2**31-1.

The following code:

class C (object):
    def __len__ (self):
       return self.l

c = C()
c.l = 2**31

len (c)

# leads to an OverflowError in the last line. It works flawless for

c.__len__ ()

----------
components: Windows
messages: 136644
nosy: peter.fankhaenel
priority: normal
severity: normal
status: open
title: Integer Overflow in __len__
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12159>
_______________________________________

From report at bugs.python.org  Mon May 23 16:27:31 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 23 May 2011 14:27:31 +0000
Subject: [issue12159] Integer Overflow in __len__
In-Reply-To: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>
Message-ID: <1306160851.05.0.358949374014.issue12159@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yep, len() has to return something less than sys.maxsize.

----------
nosy: +benjamin.peterson
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12159>
_______________________________________

From report at bugs.python.org  Mon May 23 16:30:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:30:43 +0000
Subject: [issue12159] Integer Overflow in __len__
In-Reply-To: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>
Message-ID: <1306161043.04.0.823162617748.issue12159@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

len(obj) is implemented using PyObject_Size() which is stores the result into a Py_ssize_t, and so is limited to sys.maxsize (2**31-1 or 2**63-1).

This implementation detail should be documented.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12159>
_______________________________________

From report at bugs.python.org  Mon May 23 16:31:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:31:16 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc and make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1306161076.49.0.333414043514.issue12028@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I find it strange that you propose to make a function public and remove its doc :)  Is a negative missing in the bug title?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 23 16:32:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:32:04 +0000
Subject: [issue12086] Tutorial doesn't discourage name mangling
In-Reply-To: <1305534944.68.0.723553568142.issue12086@psf.upfronthosting.co.za>
Message-ID: <1306161124.47.0.089891446385.issue12086@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/issue12086>
_______________________________________

From report at bugs.python.org  Mon May 23 16:32:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:32:40 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc or make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1306161160.83.0.366172155312.issue12028@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: threading._get_ident(): remove it in the doc and make it public -> threading._get_ident(): remove it in the doc or make it public

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 23 16:33:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:33:11 +0000
Subject: [issue12101] PEPs should have consecutive revision numbers
In-Reply-To: <1305695537.09.0.834655351659.issue12101@psf.upfronthosting.co.za>
Message-ID: <1306161191.47.0.100322728753.issue12101@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

IOW, invalid?

----------
components: +None -Devguide
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12101>
_______________________________________

From report at bugs.python.org  Mon May 23 16:33:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:33:46 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306161226.81.0.00220869155513.issue8796@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

deprecate_codecs.patch: "Deprecate open(), StreamReader, StreamWriter, StreamReaderWriter, StreamRecord and EncodedFile() of the codec module. Use the builtin open() function or io.TextIOWrapper instead."

EncodedFile() and StreamRecord cannot be replaced easily by open() or TextIOWrapper. But do we still need this function? In 2002, Martin von Loewis wrote "I never found this class useful."
http://mail.python.org/pipermail/python-dev/2002-August/027491.html

It is maybe no more useful with Python 3 which process all text data as Unicode, copy/paste of the mail thread:
------------
> In a well-designed designed application, you should not need to say
> this. The inside world should use Unicode objects.

Agreed, but if you want to port an existing application to
the Unicode world, it sometimes helps.
------------

Deprecated in Python 3.3, the related code will be removed in Python 3.4.

----------
keywords: +patch
Added file: http://bugs.python.org/file22081/deprecate_codecs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon May 23 16:34:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:34:58 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306161298.0.0.882198705726.issue8796@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Deprecate codecs.open() -> Deprecate codecs.open(), codecs.StreamReader and codecs.StreamWriter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon May 23 16:35:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:35:26 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306161326.2.0.618802375064.issue8796@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status:  -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon May 23 16:35:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:35:59 +0000
Subject: [issue6459] distutils.command.build_ext.get_export_symbols should use
	the "PyInit" prefix rather then "init"
In-Reply-To: <1247275210.18.0.83127119859.issue6459@psf.upfronthosting.co.za>
Message-ID: <1306161359.04.0.283874170721.issue6459@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed by Tarek in 406ba3cdebcb.

----------
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6459>
_______________________________________

From report at bugs.python.org  Mon May 23 16:41:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:41:31 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1306161691.47.0.680780663911.issue12077@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/issue12077>
_______________________________________

From report at bugs.python.org  Mon May 23 16:48:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:48:22 +0000
Subject: [issue1298835] Add a vendor-packages directory for system-supplied
	modules
Message-ID: <1306162102.4.0.518288499358.issue1298835@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for detailing the rationale.  Separating the ?vendor?-controlled space (or let?s call it system; not all OSes have vendors :) from the sysadmin-controlled location is indeed a real concern, as shown by the recent-ish dist-packages invention by doko for Debian.  Maybe you could get more feedback from other Python packagers on the distutils-sig, python-dev or distributions at freedesktop.org mailing list?

----------
components: +Distutils2
nosy: +alexis, barry, brett.cannon, carljm, doko, eric.araujo
title: vendor-packages directory. -> Add a vendor-packages directory for system-supplied modules
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298835>
_______________________________________

From report at bugs.python.org  Mon May 23 16:53:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:53:20 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>
Message-ID: <1306162400.87.0.613242160767.issue12055@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
versions: +Python 3.1, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Mon May 23 16:54:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:54:58 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>
Message-ID: <1306162498.69.0.972141827673.issue12055@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From http://docs.python.org/dev/library/doctest#which-docstrings-are-examined :

?The module docstring, and all function, class and method docstrings are searched. Objects imported into the module are not searched. [...] Any classes found are recursively searched similarly, to test docstrings in their contained methods and nested classes.?

The doc does not advertise support for nested functions, so this would be a new feature, if deemed useful.

----------
nosy: +eric.araujo
type:  -> feature request
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Mon May 23 16:51:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:51:22 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <1306162282.87.0.519444705144.issue12158@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> You can then use linux_version().split('.') in code that want
> to do version comparisons.

It doesn't give the expected result:

>>> ('2', '6', '9') < ('2', '6', '20')
False
>>> ('2', '6', '9') > ('2', '6', '20')
True

By the way, if you would like to *display* the Linux version, it's better to use release() which gives more information:

>>> platform.linux_version()
(2, 6, 38)
>>> platform.release()
'2.6.38-2-amd64'

About the name convention: mac_ver() and win32_ver() do return tuples. If you prefer linux_version_tuple(), it's as you want. But return a tuple of strings is useless: if you would like a string, use release() and parse the string yourself.

Note: "info" suffix is not currently used, whereas there are python_version() and python_version_tuple().

> Do we really need to expose a such Linux-centric and sparingly
> used function to the platform module?

The platform module has already 2 functions specific to Linux: linux_distribution() and libc_ver(). But if my proposed API doesn't fit platform conventions, yeah, we can move the function to test.support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 16:57:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:57:31 +0000
Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on
	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1306162651.18.0.985562355777.issue12073@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks for your review, here is an updated patch.

----------
Added file: http://bugs.python.org/file22082/regrtest_sigusr1-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12073>
_______________________________________

From report at bugs.python.org  Mon May 23 16:57:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:57:35 +0000
Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on
	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1306162655.87.0.0383121342431.issue12073@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file21995/regrtest_sigusr1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12073>
_______________________________________

From report at bugs.python.org  Mon May 23 16:57:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:57:38 +0000
Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on
	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1306162658.83.0.96312776698.issue12073@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22067/regrtest_sigusr1-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12073>
_______________________________________

From report at bugs.python.org  Mon May 23 16:58:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 14:58:06 +0000
Subject: [issue12073] regrtest: use faulthandler to dump the tracebacks on
	SIGUSR1
In-Reply-To: <1305327717.08.0.00592057633309.issue12073@psf.upfronthosting.co.za>
Message-ID: <1306162686.97.0.125074047031.issue12073@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Merwok's review:
<< Looks like a useful feature.


http://bugs.python.org/review/12073/diff/2659/6441
File Lib/test/regrtest.py (right):

http://bugs.python.org/review/12073/diff/2659/6441#newcode164
Lib/test/regrtest.py:164: You can send a SIGUSR1 signal to display the
traceback of the current threads.
?the traceback? (singular) ?of the current threads? (plural) sounds a
bit strange to me: There is one traceback for many threads?

http://bugs.python.org/review/12073/diff/2659/6441#newcode165
Lib/test/regrtest.py:165: But send a signal may interrupt the current
system call and so interfer with
?Note that sending a signal may interrupt a system call in progress and
thus interfere with the tests, so only do it if a test hangs and you
want to know where.?

http://bugs.python.org/review/12073/show >>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12073>
_______________________________________

From report at bugs.python.org  Mon May 23 16:58:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 14:58:57 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <1306162737.41.0.0873323453901.issue12074@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on the idea.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Mon May 23 17:01:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 15:01:30 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1306162890.52.0.0381284344743.issue11957@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d favor 1) or 2) over 3).  Ints are short and very commonly used for flags.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Mon May 23 17:02:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 15:02:48 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306162968.19.0.566326474295.issue12042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure historical whatsnew documents get fixes.  As long as the PEPs and docs get fixes, the whatsnew can stay as they are.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Mon May 23 17:05:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 15:05:29 +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: <1306163129.12.0.992385595009.issue12141@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Mon May 23 17:08:53 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 23 May 2011 15:08:53 +0000
Subject: [issue12081] Remove distributed copy of libffi
In-Reply-To: <1305473826.35.0.492427702467.issue12081@psf.upfronthosting.co.za>
Message-ID: <1306163333.23.0.754117630403.issue12081@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

iirc after merging 3.0.9, we still had to use the internal libffi bits for windows and macosx. I didn't check 3.0.10rc8

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12081>
_______________________________________

From report at bugs.python.org  Mon May 23 17:09:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 15:09:39 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306163379.4.0.304232815047.issue12154@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your work!  Feel free to post the patch so that it won?t get lost.  It may be that it ports cleanly or with trivial adaptations to 3.x, I can test and report if you don?t want to set up a full devel environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12154>
_______________________________________

From report at bugs.python.org  Mon May 23 17:15:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 23 May 2011 15:15:30 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306163730.0.0.807316706194.issue12154@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/issue12154>
_______________________________________

From report at bugs.python.org  Mon May 23 17:15:41 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Mon, 23 May 2011 15:15:41 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>
Message-ID: <1306163741.32.0.348800708505.issue12055@psf.upfronthosting.co.za>


Baptiste Carvello <devel at baptiste-carvello.net> added the comment:

Hello,

the attached patch adds the requested feature to 3.2 (the patch is based on 6d67931c63f9), with appropriate doc changes and tests for the new behaviour.

It does not apply to 2.7, so I'll send another patch for that soon.

----------
keywords: +patch
nosy: +baptiste.carvello
type: feature request -> 
versions: +Python 2.6, Python 2.7 -Python 3.3
Added file: http://bugs.python.org/file22083/issue12055-32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Mon May 23 17:28:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2011 15:28:07 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306164487.45.0.482544093788.issue12152@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

And like Benjamin said, it should be enough to touch those two files.  You don't have to actually build a release tarball.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 17:29:50 2011
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 23 May 2011 15:29:50 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306164590.66.0.233209244562.issue12152@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

ok, thanks. good enough

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Mon May 23 17:48:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 15:48:37 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>
Message-ID: <1306165717.83.0.874097054895.issue12055@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

New features don?t go in stable versions.

----------
type:  -> feature request
versions: +Python 3.3 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Mon May 23 17:55:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 15:55:37 +0000
Subject: [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Codec.encode() and Codec.decode() refer to StreamCode, but I cannot find this class in the doc nor in the code.

I suppose that it should be replaced by IncrementalEncoder and IncrementalDecoder. If I'm correct, see attached patch.

----------
files: codecs_incremental.patch
keywords: patch
messages: 136665
nosy: haypo, lemburg
priority: normal
severity: normal
status: open
title: codecs doc: what is StreamCodec?
Added file: http://bugs.python.org/file22084/codecs_incremental.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12160>
_______________________________________

From report at bugs.python.org  Mon May 23 18:11:58 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 16:11:58 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306167118.8.0.00152126194396.issue8796@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Closing the ticket again.

We still need codecs.open() to support applications that target Python 2.x and 3.x.

You can reopen it after Python 2.x has been end-of-life'd.

----------
resolution:  -> postponed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon May 23 18:13:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 16:13:19 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <E1QOXkr-0002m9-NN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5783a55a2418 by Victor Stinner in branch 'default':
Issue #6501: os.device_encoding() returns None on Windows if the application
http://hg.python.org/cpython/rev/5783a55a2418

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Mon May 23 18:14:20 2011
From: report at bugs.python.org (Philip Drew)
Date: Mon, 23 May 2011 16:14:20 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306167260.42.0.485732691856.issue12140@psf.upfronthosting.co.za>


Philip Drew <pwtdrew at gmail.com> added the comment:

Gave it a go: the prompt appears, but none of the functions work thereafter

C:\Users\PWTD>c:\Python27\python -S
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
>>> print "hello"

LookupError: no codec search functions registered: can't find encoding
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Mon May 23 18:15:06 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Mon, 23 May 2011 16:15:06 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <1306163741.32.0.348800708505.issue12055@psf.upfronthosting.co.za>
Message-ID: <4DDA87E0.8070900@baptiste-carvello.net>


Baptiste Carvello <devel at baptiste-carvello.net> added the comment:

here is the patch for 2.7.

Dave: I don't know if or when the patch will be accepted, as this is a new 
feature. In the meantime, you can easily patch your system. As the code changes 
are all in Python, you don't need to recompile. Going to your standard library 
directory and running a command like the following should do the trick:

filterdiff -i '*/doctest.py' issue12055-27.diff | patch

----------
Added file: http://bugs.python.org/file22085/issue12055-27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/doctest.rst b/Doc/library/doctest.rst
--- a/Doc/library/doctest.rst
+++ b/Doc/library/doctest.rst
@@ -280,7 +280,7 @@
 searched.  Objects imported into the module are not searched.
 
 In addition, if ``M.__test__`` exists and "is true", it must be a dict, and each
-entry maps a (string) name to a function object, class object, or string.
+entry maps a (string) name to a function object, code object, class object, or string.
 Function and class object docstrings found from ``M.__test__`` are searched, and
 strings are treated as if they were docstrings.  In output, a key ``K`` in
 ``M.__test__`` appears with name ::
@@ -293,6 +293,12 @@
 .. versionchanged:: 2.4
    A "private name" concept is deprecated and no longer documented.
 
+Any functions found are recursively searched similarly, to test docstrings in 
+their contained nested functions (nested functions exist as a code object constant).
+
+Any code objects found, be it in ``M.__test__`` or nested in a function, are recursively 
+searched similarly, to test docstrings in their contained nested functions.
+
 
 .. _doctest-finding-examples:
 
diff --git a/Lib/doctest.py b/Lib/doctest.py
--- a/Lib/doctest.py
+++ b/Lib/doctest.py
@@ -98,6 +98,7 @@
 import sys, traceback, inspect, linecache, os, re
 import unittest, difflib, pdb, tempfile
 import warnings
+import types
 from StringIO import StringIO
 from collections import namedtuple
 
@@ -814,7 +815,10 @@
         """
         # If name was not specified, then extract it from the object.
         if name is None:
-            name = getattr(obj, '__name__', None)
+            if type(obj) != types.CodeType:
+                name = getattr(obj, '__name__', None)
+            else:
+                name = getattr(obj, 'co_name', None)
             if name is None:
                 raise ValueError("DocTestFinder.find: name must be given "
                         "when obj.__name__ doesn't exist: %r" %
@@ -925,17 +929,34 @@
                     raise ValueError("DocTestFinder.find: __test__ keys "
                                      "must be strings: %r" %
                                      (type(valname),))
-                if not (inspect.isfunction(val) or inspect.isclass(val) or
-                        inspect.ismethod(val) or inspect.ismodule(val) or
-                        isinstance(val, basestring)):
+                if not (inspect.isfunction(val) or inspect.iscode(val) or
+                        inspect.isclass(val) or inspect.ismethod(val) or
+                        inspect.ismodule(val) or isinstance(val, basestring)):
                     raise ValueError("DocTestFinder.find: __test__ values "
-                                     "must be strings, functions, methods, "
+                                     "must be strings, functions, "
+                                     "code objects, methods, "
                                      "classes, or modules: %r" %
                                      (type(val),))
                 valname = '%s.__test__.%s' % (name, valname)
                 self._find(tests, val, valname, module, source_lines,
                            globs, seen)
 
+        # Look for tests in a function's contained objects.
+        if inspect.isfunction(obj) and self._recurse:
+            for val in obj.__code__.co_consts:
+                if inspect.iscode(val):
+                    valname = '%s.%s' % (name, val.co_name)
+                    self._find(tests, val, valname, module, source_lines,
+                               globs, seen)
+
+        # Look for tests in a code object's contained objects.
+        if inspect.iscode(obj) and self._recurse:
+            for val in obj.co_consts:
+                if inspect.iscode(val):
+                    valname = '%s.%s' % (name, val.co_name)
+                    self._find(tests, val, valname, module, source_lines,
+                               globs, seen)
+
         # Look for tests in a class's contained objects.
         if inspect.isclass(obj) and self._recurse:
             for valname, val in obj.__dict__.items():
@@ -962,6 +983,16 @@
         # then return None (no test for this object).
         if isinstance(obj, basestring):
             docstring = obj
+        elif inspect.iscode(obj):
+            try:
+                if obj.co_consts[0] is None:
+                    docstring = ''
+                else:
+                    docstring = obj.co_consts[0]
+                    if not isinstance(docstring, str):
+                        docstring = str(docstring)
+            except (TypeError, AttributeError, IndexError):
+                docstring = ''
         else:
             try:
                 if obj.__doc__ is None:
diff --git a/Lib/test/test_doctest.py b/Lib/test/test_doctest.py
--- a/Lib/test/test_doctest.py
+++ b/Lib/test/test_doctest.py
@@ -25,6 +25,40 @@
     """
     return v+v
 
+def sample_outer_func(v):
+
+    def sample_nested_func(w):
+        """
+        Blah blah
+
+        >>> print sample_outer_func(22)(42)
+        64
+
+        Yee ha!
+        """
+        return v+w
+
+    return sample_nested_func
+
+def sample_outer_func_2(v):
+
+    def sample_nested_func(w):
+
+        def sample_doubly_nested_func(x):
+            """
+            Blah blah
+
+            >>> print sample_outer_func_2(22)(42)(28)
+            92
+
+            Yee ha!
+            """
+            return v+w+x
+
+        return sample_doubly_nested_func
+
+    return sample_nested_func
+
 class SampleClass:
     """
     >>> print 1
@@ -415,6 +449,51 @@
     >>> finder.find(no_examples) # doctest: +ELLIPSIS
     [<DocTest no_examples from ...:1 (no examples)>]
 
+If a function's code object contains code objects in co_consts, as is the 
+case for nested functions, docstrings are searched in those code objects
+
+    >>> tests = finder.find(sample_outer_func)
+    >>> for t in tests:
+    ...     print '%2s  %s' % (len(t.examples), t.name)
+     1  sample_outer_func.sample_nested_func
+    >>> e = tests[0].examples[0]
+    >>> (e.source, e.want, e.lineno)
+    ('print sample_outer_func(22)(42)\n', '64\n', 3)
+
+This also works for multiply nested functions
+
+    >>> tests = finder.find(sample_outer_func_2)
+    >>> for t in tests:
+    ...     print '%2s  %s' % (len(t.examples), t.name)
+     1  sample_outer_func_2.sample_nested_func.sample_doubly_nested_func
+    >>> e = tests[0].examples[0]
+    >>> (e.source, e.want, e.lineno)
+    ('print sample_outer_func_2(22)(42)(28)\n', '92\n', 3)
+
+Finding Tests in Code Objects
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Code objects are treated the same as functions
+
+    >>> finder = doctest.DocTestFinder()
+    >>> tests = finder.find(sample_func.__code__)
+    >>> for t in tests:
+    ...     print '%2s  %s' % (len(t.examples), t.name)
+     1  sample_func
+    >>> e = tests[0].examples[0]
+    >>> (e.source, e.want, e.lineno)
+    ('print sample_func(22)\n', '44\n', 3)
+
+Nested functions are supported
+
+    >>> tests = finder.find(sample_outer_func.__code__)
+    >>> for t in tests:
+    ...     print '%2s  %s' % (len(t.examples), t.name)
+     1  sample_outer_func.sample_nested_func
+    >>> e = tests[0].examples[0]
+    >>> (e.source, e.want, e.lineno)
+    ('print sample_outer_func(22)(42)\n', '64\n', 3)
+
 Finding Tests in Classes
 ~~~~~~~~~~~~~~~~~~~~~~~~
 For a class, DocTestFinder will create a test for the class's
@@ -470,7 +549,8 @@
     ...         ''',
     ...     '__test__': {
     ...         'd': '>>> print 6\n6\n>>> print 7\n7\n',
-    ...         'c': triple}})
+    ...         'c': triple,
+    ...         'sample_nested_func_codeobj': sample_outer_func.__code__.co_consts[1]}})
 
     >>> finder = doctest.DocTestFinder()
     >>> # Use module=test.test_doctest, to prevent doctest from
@@ -491,6 +571,7 @@
      1  some_module.SampleClass.get
      1  some_module.__test__.c
      2  some_module.__test__.d
+     1  some_module.__test__.sample_nested_func_codeobj
      1  some_module.sample_func
 
 Duplicate Removal

From report at bugs.python.org  Mon May 23 18:17:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 16:17:20 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1306167440.96.0.918506813933.issue6501@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@grahamd: Can you try the development version of Python 3.3, or try to patch your version using device_encoding.patch? You will not get cp0 encoding anymore.

If the patch fixes your issue, I will backport it. I don't see anything interesting to do for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Mon May 23 18:20:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 16:20:43 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1306167118.8.0.00152126194396.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306167641.26710.0.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le lundi 23 mai 2011 ? 16:11 +0000, Marc-Andre Lemburg a ?crit :
> We still need codecs.open() to support applications that target Python 2.x and 3.x.

io.TextIOWrapper exists in Python 2.6 and 2.7, and 2to3 can simply
replace codecs.open() by open().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon May 23 18:21:21 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 16:21:21 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306167681.22.0.0519616958649.issue8796@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Correcting the title: this ticket is about codecs.open(), not StreamRead and StreamWriter, both of which are essential parts of the Python codec machinery and are needed to be able to implement per-codec implementations of codecs which read from and write to streams.

TextIOWrapper() is conceptually something completely different. It's more something like StreamReaderWriter().

The point about having them use incremental codecs for encoding and decoding is a good one and would need to be investigated. If possible, we could use incremental encoders/decoders for the standard StreamReader/Writer base classes or add new IncrementalStreamReader/Writer classes which then use the IncrementalEncode/Decoder per default.

Please open a new ticket for this.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Mon May 23 18:21:31 2011
From: report at bugs.python.org (Dave Abrahams)
Date: Mon, 23 May 2011 16:21:31 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <4DDA87E0.8070900@baptiste-carvello.net>
Message-ID: <BANLkTinBuEdH0HOUXLFaLREp5SrKpkKoFw@mail.gmail.com>


Dave Abrahams <dave at boostpro.com> added the comment:

It's certainly much appreciated, but my tests have to run with a stock
python, so I worked around the problem  personally.  I just reported
this because I found (surprisingly, to me) that some of my tests had
been silently not-running, which seems like a bad feature of any
testing system ;=).

On Mon, May 23, 2011 at 12:15 PM, Baptiste Carvello
<report at bugs.python.org> wrote:
>
> Baptiste Carvello <devel at baptiste-carvello.net> added the comment:
>
> here is the patch for 2.7.
>
> Dave: I don't know if or when the patch will be accepted, as this is a new
> feature. In the meantime, you can easily patch your system. As the code changes
> are all in Python, you don't need to recompile. Going to your standard library
> directory and running a command like the following should do the trick:
>
> filterdiff -i '*/doctest.py' issue12055-27.diff | patch
>
> ----------
> Added file: http://bugs.python.org/file22085/issue12055-27.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12055>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Mon May 23 18:23:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 23 May 2011 16:23:41 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306167821.6.0.459737210053.issue12140@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

>From a Windows command prompt:
- what is the output of "chcp"?
- maybe an environment variable issue? Try "set PY" to display all variables starting with PY.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Mon May 23 18:23:54 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 16:23:54 +0000
Subject: [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <4DDA8A17.1020304@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> Codec.encode() and Codec.decode() refer to StreamCode, but I cannot find this class in the doc nor in the code.
> 
> I suppose that it should be replaced by IncrementalEncoder and IncrementalDecoder. If I'm correct, see attached patch.

Thanks for spotting this.

It should read StreamReader/StreamWriter, since these were designed
to keep state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12160>
_______________________________________

From report at bugs.python.org  Mon May 23 18:24:42 2011
From: report at bugs.python.org (Davi Post)
Date: Mon, 23 May 2011 16:24:42 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306167882.04.0.506124485238.issue12042@psf.upfronthosting.co.za>


Davi Post <post at pobox.com> added the comment:

The What's New docs are the place to find information on changes between versions. Upgrading to 2.7 from 2.5, I needed to read the 2.6 and 2.7 What's New docs to learn what changes I should be aware of. I hope errors in these docs will be fixed, at least for a few versions back. (This particular fix is not so important, but I'm trying to practice the habit of at least reporting problems I see, to make a contribution to Python.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Mon May 23 18:34:24 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Mon, 23 May 2011 16:34:24 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306168464.53.0.580014359267.issue12042@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

Alright, should it be closed if we aren't going to touch it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Mon May 23 18:40:26 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 16:40:26 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306162282.87.0.519444705144.issue12158@psf.upfronthosting.co.za>
Message-ID: <4DDA8DF6.1090403@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> You can then use linux_version().split('.') in code that want
>> to do version comparisons.
> 
> It doesn't give the expected result:
> 
>>>> ('2', '6', '9') < ('2', '6', '20')
> False
>>>> ('2', '6', '9') > ('2', '6', '20')
> True

Sorry, I forgot the tuple(int(x) for ...) part.

> By the way, if you would like to *display* the Linux version, it's better to use release() which gives more information:

No, release() doesn't have any defined format.

>>>> platform.linux_version()
> (2, 6, 38)
>>>> platform.release()
> '2.6.38-2-amd64'
> 
> About the name convention: mac_ver() and win32_ver() do return tuples. If you prefer linux_version_tuple(), it's as you want. But return a tuple of strings is useless: if you would like a string, use release() and parse the string yourself.

Please look again: they both return the version and other infos as
strings.

> Note: "info" suffix is not currently used, whereas there are python_version() and python_version_tuple().

Good point. I was thinking of the sys module function to
return the Python version as tuple.

>> Do we really need to expose a such Linux-centric and sparingly
>> used function to the platform module?
> 
> The platform module has already 2 functions specific to Linux: linux_distribution() and libc_ver(). But if my proposed API doesn't fit platform conventions, yeah, we can move the function to test.support.

Indeed and in retrospect, adding linux_distribution() was a mistake,
since it causes too much maintenance.

The linux_version() is likely going to cause similar issues, since
on the systems I checked, some return three part versions,
others four parts and then again other add a distribution specific
revision counter to it.

Then you have pre-releases, release candidates and development
versions:

http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

Reconsidering, I think it's better not to add the API to prevent
opening up another can of worms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 18:41:03 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 16:41:03 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <1306168863.86.0.794468909015.issue12158@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Mon May 23 18:45:18 2011
From: report at bugs.python.org (Philip Drew)
Date: Mon, 23 May 2011 16:45:18 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306169118.96.0.639480667507.issue12140@psf.upfronthosting.co.za>


Philip Drew <pwtdrew at gmail.com> added the comment:

C:\Users\PWTD>set PY
PYTHONHOME=c:\program files (x86)\steam\steamapps\common\alien swarm\swarm\..\sdktools\python\2.5

C:\Users\PWTD>chcp
Active code page: 850

C:\Users\PWTD>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Mon May 23 18:47:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2011 16:47:47 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <1306169267.38.0.342340614274.issue12074@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How about instead changing [1/4], [2/4] etc to be [1/4/0], [2/4/0], etc?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Mon May 23 18:54:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 May 2011 16:54:38 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306169678.37.0.0332580116632.issue12042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let?s fix it in the open branches.

----------
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Mon May 23 19:04:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 23 May 2011 17:04:31 +0000
Subject: [issue10801] zipfile.ZipFile().extractall() header mismatch for
	non-ASCII characters
In-Reply-To: <1293802719.05.0.954235124812.issue10801@psf.upfronthosting.co.za>
Message-ID: <1306170271.27.0.214412683743.issue10801@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Victor: you should have a look at <http://bitbucket.org/birkenfeld/hgcodesmell>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10801>
_______________________________________

From report at bugs.python.org  Mon May 23 19:07:43 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 23 May 2011 17:07:43 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1306170463.28.0.604614394603.issue12125@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12125>
_______________________________________

From report at bugs.python.org  Mon May 23 19:07:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 May 2011 17:07:44 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306170464.76.0.364432107056.issue5715@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Antoine, do you think we can commit this as-is (i.e. without specific test)?
If yes, to what branches (I'm not really sure of what kind of change is allowed for each branch, is there a document somewhere detailing the official policy?) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Mon May 23 19:08:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 17:08:07 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <E1QOYbt-00084D-Na@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f86fdca477e3 by Tarek Ziade in branch 'default':
Issue #12125: fixed the failures under Solaris due to improper test cleanup.
http://hg.python.org/cpython/rev/f86fdca477e3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12125>
_______________________________________

From report at bugs.python.org  Mon May 23 19:10:11 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 23 May 2011 17:10:11 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306170611.76.0.960487037011.issue12140@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

hmm, I don't like this PYTHONHOME. Can you reset its value and run python again in the same terminal?

C:\Users\PWTD>set PYTHONHOME=
C:\Users\PWTD>c:\Python27\python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Mon May 23 19:36:43 2011
From: report at bugs.python.org (JJeffries)
Date: Mon, 23 May 2011 17:36:43 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306172203.1.0.122193037779.issue12154@psf.upfronthosting.co.za>


JJeffries <jamesjeffries1 at gmail.com> added the comment:

Tested this on 2.7.1. currently only covers the HTMLDoc class. The TextDoc class will also need updating with the docpartialfunc method.

----------
keywords: +patch
Added file: http://bugs.python.org/file22086/partial.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12154>
_______________________________________

From report at bugs.python.org  Mon May 23 20:04:37 2011
From: report at bugs.python.org (Baptiste Carvello)
Date: Mon, 23 May 2011 18:04:37 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <BANLkTinBuEdH0HOUXLFaLREp5SrKpkKoFw@mail.gmail.com>
Message-ID: <4DDAA18B.5010809@baptiste-carvello.net>


Baptiste Carvello <devel at baptiste-carvello.net> added the comment:

Eric: my bad, I guess I was living in the past, before 3.2 was released :-)

Anyway, my 3.2 patch applies to default (6354b4ceba1d), with just a one-line 
offset for test_doctest.py. All tests pass.

By the way, my 2.7 patch was based on 76e5fe8e21fd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Mon May 23 20:56:30 2011
From: report at bugs.python.org (David Watson)
Date: Mon, 23 May 2011 18:56:30 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <4DDA2306.4000805@duodecad.hu>
Message-ID: <20110523185628.GA2978@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

On Mon 23 May 2011, Gergely K?lm?n wrote:
> It's been a while I had a look at that code. As far as I remember though 
> the code is fairly decent not
> taking the missing unit tests into account. There are a few todos, and 
> also a pretty bad bug that I've fixed
> but not committed. The TODOs include better parsing of auxiliary data, 
> support for scatter-gather, addressed
> messages. If you wish I can send you the latest patch that has the bug 
> fixed and applies to 3.2.

Erm, have you seen the separately-implemented patch I posted at
http://bugs.python.org/file19962/baikie-hwundram-v5.diff ?  It's
basically complete IIRC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon May 23 21:04:25 2011
From: report at bugs.python.org (Nir Aides)
Date: Mon, 23 May 2011 19:04:25 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306177465.94.0.258401418778.issue1625@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Hi, I attach a patch to Python 3.3 Lib/bz2.py with updated tests:
cpython-bz2-streams.patch

----------
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22087/cpython-bz2-streams.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon May 23 21:30:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 23 May 2011 19:30:00 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306179000.94.0.29755171243.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Thanks for the patch. I'll review it tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon May 23 21:51:07 2011
From: report at bugs.python.org (poq)
Date: Mon, 23 May 2011 19:51:07 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1306180267.82.0.409919529805.issue12134@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

Alright.

I wouldn't mind a little note in the docs; I certainly did not expect that these two functions would perform so differently.

Would it be very difficult though to add buffering support the C encoder?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Mon May 23 22:02:42 2011
From: report at bugs.python.org (alejandro david weil)
Date: Mon, 23 May 2011 20:02:42 +0000
Subject: [issue12161] StringIO AttributeError instead of ValueError after
	close..
In-Reply-To: <1306180961.98.0.624662608514.issue12161@psf.upfronthosting.co.za>
Message-ID: <1306180961.98.0.624662608514.issue12161@psf.upfronthosting.co.za>


New submission from alejandro david weil <tenuki at gmail.com>:

python 2.7 documentation: file:///usr/share/doc/python-doc/html/library/stringio.html#StringIO.StringIO.close
(or: http://docs.python.org/library/stringio.html#StringIO.StringIO.close )

says:

"""StringIO.close()

Free the memory buffer. Attempting to do further operations with a closed StringIO object will raise a ValueError."""


But this code:

def string_io_close_exception_test():
    from StringIO import StringIO
    s=StringIO()
    s.write("asdf")
    s.close()
    try:
        # file:///usr/share/doc/python-doc/html/library/stringio.html#StringIO.StringIO.close
        doc = """
        StringIO.close()
Free the memory buffer. Attempting to do further operations with a closed StringIO object will raise a ValueError.
        """
        s.getvalue()
    except ValueError:
        print "this is the expected"
    except Exception, e:
        print 'this is unexpected:',type(e), e
        raise

produces this output:


this is unexpected: <type 'exceptions.AttributeError'> StringIO instance has no attribute 'buf'
Traceback (most recent call last):
  File "problems.py", line 192, in <module>
    string_io()
  File "problems.py", line 184, in string_io
    s.getvalue()
  File "/usr/lib/python2.7/StringIO.py", line 270, in getvalue
    self.buf += ''.join(self.buflist)
AttributeError: StringIO instance has no attribute 'buf'

----------
components: Library (Lib)
messages: 136692
nosy: tenuki
priority: normal
severity: normal
status: open
title: StringIO AttributeError instead of ValueError after close..
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12161>
_______________________________________

From report at bugs.python.org  Mon May 23 22:22:14 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Mon, 23 May 2011 20:22:14 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1306182134.36.0.644097153524.issue1813@psf.upfronthosting.co.za>


Changes by G?k?en Eraslan <gokcen at pardus.org.tr>:


----------
nosy: +G?k?en.Eraslan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Mon May 23 22:38:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 20:38:05 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <E1QObt6-0002PP-Gt@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7980838e2f55 by Vinay Sajip in branch 'default':
Issue #12151: Added diagnostics to help diagnose intermittent socket errors.
http://hg.python.org/cpython/rev/7980838e2f55

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 23 22:49:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 20:49:17 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <E1QOc3w-0003TO-Mu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9ea03afc81f4 by Vinay Sajip in branch 'default':
Issue #12151: Correction to diagnostic code.
http://hg.python.org/cpython/rev/9ea03afc81f4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 23 23:16:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 21:16:12 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <E1QOcTy-0005k9-PD@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 2da7577fa393 by Victor Stinner in branch '3.2':
Issue #12074: regrtest displays also the current number of failures
http://hg.python.org/cpython/rev/2da7577fa393

New changeset 60b0131fbea8 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12074: regrtest displays also the current number of failures
http://hg.python.org/cpython/rev/60b0131fbea8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Mon May 23 23:16:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 May 2011 21:16:33 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306185393.82.0.66263909595.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

@Victor
Since linux_version() won't be added to the platform module, could you add it to test.support so that it can be used in the O_CLOEXEC test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Mon May 23 23:17:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2011 21:17:00 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <1306185420.41.0.704874290613.issue12074@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> How about instead changing [1/4], [2/4] etc 
> to be [1/4/0], [2/4/0], etc?

Great, I like it, and it's commited.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Mon May 23 23:23:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 May 2011 21:23:31 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1306167681.22.0.0519616958649.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306185807.3548.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> TextIOWrapper() is conceptually something completely different. It's
> more something like StreamReaderWriter().

That's a rather strange assertion. Can you expand?
TextIOWrapper supports read-only, write-only, read-write, unseekable and
seekable streams.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 24 00:00:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 22:00:50 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <E1QOdBB-0001Cg-58@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 1b1471d50b9e by Vinay Sajip in branch 'default':
Issue #12151: Test now ignores datagram socket errors after server is closed.
http://hg.python.org/cpython/rev/1b1471d50b9e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Tue May 24 00:02:05 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 May 2011 22:02:05 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1306185807.3548.0.camel@localhost.localdomain>
Message-ID: <4DDAD958.9030007@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> TextIOWrapper() is conceptually something completely different. It's
>> more something like StreamReaderWriter().
> 
> That's a rather strange assertion. Can you expand?
> TextIOWrapper supports read-only, write-only, read-write, unseekable and
> seekable streams.

StreamReader and StreamWriter classes provide the base codec
implementations for stateful interaction with streams. They
define the interface and provide a working implementation for
those codecs that choose not to implement their own variants.

Each codec can, however, implement variants which are optimized
for the specific encoding or intercept certain stream methods
to add functionality or improve the encoding/decoding
performance.

Both are essential parts of the codec interface.

TextIOWrapper and StreamReaderWriter are merely wrappers
around streams that make use of the codecs. They don't
provide any codec logic themselves. That's the conceptual
difference.

----------
title: Deprecate codecs.open(), codecs.StreamReader and codecs.StreamWriter -> Deprecate codecs.open(),	codecs.StreamReader and codecs.StreamWriter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 24 00:04:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 May 2011 22:04:06 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306188246.95.0.55096047917.issue5715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, do you think we can commit this as-is (i.e. without specific
> test)?

Yes.

> If yes, to what branches (I'm not really sure of what kind of change is 
> allowed for each branch, is there a document somewhere detailing the
> official policy?) ?

I think 2.7, 3.1, 3.2 and default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 00:04:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 22:04:17 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <E1QOdEW-0001Mq-2E@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 396f4ed61db7 by Ezio Melotti in branch '3.2':
#12074: remove the /0 when there are no failures.
http://hg.python.org/cpython/rev/396f4ed61db7

New changeset 9de2b1a5ee6b by Ezio Melotti in branch 'default':
#12074: merge with 3.2.
http://hg.python.org/cpython/rev/9de2b1a5ee6b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Tue May 24 00:06:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 23 May 2011 22:06:57 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1306188417.88.0.664662926829.issue10994@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The __sizeof__ special attribute shows up in dir(object) but appears not to be documented other than with

>>> help(object.__sizeof__)
Help on method_descriptor:
__sizeof__(...)
    __sizeof__() -> size of object in memory, in bytes

Should it have an entry in Lib 4.12. Special Attributes?

object.__sizeof__
    A method used by sys.getsizeof.

It should then show up in the index (missing now) and point people to sys.getsizeof.  Looking further, I see that it is mentioned but not indexed in the sys.getsizeof entry.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10994>
_______________________________________

From report at bugs.python.org  Tue May 24 00:07:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 23 May 2011 22:07:04 +0000
Subject: [issue12074] regrtest: display the current number of failures
In-Reply-To: <1305328560.39.0.298265864552.issue12074@psf.upfronthosting.co.za>
Message-ID: <1306188424.28.0.273548861862.issue12074@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I removed the /0 when there are no failures after a short discussion on #python-dev.  FWIW I'm -0 on the /N, but now that it's not displayed if there are no failures it won't bother me too much.

----------
nosy: +ezio.melotti
stage:  -> committed/rejected
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12074>
_______________________________________

From report at bugs.python.org  Tue May 24 00:17:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 22:17:02 +0000
Subject: [issue11377] Deprecate platform.popen()
In-Reply-To: <1299086966.45.0.602666513721.issue11377@psf.upfronthosting.co.za>
Message-ID: <E1QOdQq-0002Iu-NT@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e44b851d0a2b by Victor Stinner in branch 'default':
Issue #11377: platform.popen() emits a DeprecationWarning
http://hg.python.org/cpython/rev/e44b851d0a2b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11377>
_______________________________________

From report at bugs.python.org  Tue May 24 00:24:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 22:24:26 +0000
Subject: [issue12158] platform: add linux_version()
In-Reply-To: <1306153526.98.0.695363771693.issue12158@psf.upfronthosting.co.za>
Message-ID: <E1QOdY1-0002om-71@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d585a6d548a3 by Victor Stinner in branch 'default':
Issue #12158: Move linux_version() from test_socket to test.support
http://hg.python.org/cpython/rev/d585a6d548a3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________

From report at bugs.python.org  Tue May 24 00:29:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2011 22:29:48 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <E1QOddD-0003A8-Eq@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9a16fa0c9548 by Victor Stinner in branch 'default':
Issue #12105: test_posix skips test_oscloexec() on Linux < 2.6.23
http://hg.python.org/cpython/rev/9a16fa0c9548

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Tue May 24 02:07:37 2011
From: report at bugs.python.org (Seth Troisi)
Date: Tue, 24 May 2011 00:07:37 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>


New submission from Seth Troisi <braintwo at gmail.com>:

It would be nice to clarify re documentation on how to use \number.

current documentation lists three half examples:
"(.+) \1 matches 'the the' or '55 55', but not 'the end' (note the space after the group)."

This is rather confusing (at least to me) as it might be assumed that
re.search("(.+) \1", "the the") would return a match, which it does not.

A better example would be re.search("(\w+) \\1", "the the") which does match.

the other confusing portion is the requirement of the second "\" to make it match.

I would think that a quick example below the text would help.

>>> re.search("(\w+) \\1", "can you do the can can?") # \\1 matches the second can at the end of the sentence
<_sre.SRE_Match object at ...>

This is my first python issue and if I have misfiled or left out some information please tell me how to proceed.

----------
assignee: docs at python
components: Documentation
messages: 136708
nosy: Seth.Troisi, docs at python
priority: normal
severity: normal
status: open
title: Documentation about re \number
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12162>
_______________________________________

From report at bugs.python.org  Tue May 24 02:12:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 May 2011 00:12:32 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306195952.51.0.158522055339.issue12162@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/issue12162>
_______________________________________

From report at bugs.python.org  Tue May 24 02:54:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2011 00:54:15 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306198455.45.0.282867243316.issue12162@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Read the description of strings and raw strings at the top of the re documentation for the answer to your question about \\.  It would probably be better if the example regular expression was written r'(.+) \1' instead of as a bare expression as it is now.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12162>
_______________________________________

From report at bugs.python.org  Tue May 24 03:08:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 May 2011 01:08:33 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1306199313.68.0.791938399625.issue12155@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Tue May 24 03:17:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 May 2011 01:17:50 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1306199870.47.0.479921204892.issue12155@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> It doesn't define do_work(), num_worker_threads or do_work()

Is it unclear to you what those mean?  They are placeholders for the user's actual task at hand.

> my concern is that it doesn't stop worker threads.

Stopping the threads wasn't the intent of the example.

> I consider "t.daemon = True" as an hack to not care 
> about stopping threads.

If you post a high-quality self-contained example somewhere on the net, I would be happy to link to it.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Tue May 24 04:01:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 24 May 2011 02:01:40 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306202500.35.0.889875361966.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Here's standalone patch which should cover this problem. The patch fails right now but succeeds if you apply it back to 652baf23c368 (the changeset before one of several changes around this code). I'll try to find the actual offending checkin and workout the differences to make a fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file22088/test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue May 24 04:10:15 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 24 May 2011 02:10:15 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1306203015.92.0.184460470427.issue12029@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Scouting around the CPython codebase a bit, I speculate that the cause of this behavior is that PyErr_GivenExceptionMatches() in errors.c uses PyType_IsSubtype() [which simply walks a class's __mro__ checking for pointer equality] rather than PyObject_IsSubclass()/PyObject_IsInstance() [which are smart enough to consult __subclasscheck__()/__instancecheck__() if they exist].

Of course, the more important issue here is whether this behavior is intended or not. I surmise python-dev needs to have a discussion about it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Tue May 24 04:10:26 2011
From: report at bugs.python.org (py.user)
Date: Tue, 24 May 2011 02:10:26 +0000
Subject: [issue12163] str.count
In-Reply-To: <1306203026.57.0.880785470377.issue12163@psf.upfronthosting.co.za>
Message-ID: <1306203026.57.0.880785470377.issue12163@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

specification says
[code]
str.count(sub[, start[, end]])

    Return the number of non-overlapping occurrences of substring sub in the range [start, end]. Optional arguments start and end are interpreted as in slice notation.
[/code]

[code]
>>> ''.count('', None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: slice indices must be integers or None or have an __index__ method
>>>
[/code]

----------
messages: 136713
nosy: py.user
priority: normal
severity: normal
status: open
title: str.count
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12163>
_______________________________________

From report at bugs.python.org  Tue May 24 04:20:17 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 24 May 2011 02:20:17 +0000
Subject: [issue11377] Deprecate platform.popen()
In-Reply-To: <1299086966.45.0.602666513721.issue11377@psf.upfronthosting.co.za>
Message-ID: <1306203617.16.0.127433475058.issue11377@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Slight tangent: Regarding os.popen()'s [documentation] status, there's a bug for that: http://bugs.python.org/issue9382

----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11377>
_______________________________________

From report at bugs.python.org  Tue May 24 04:27:05 2011
From: report at bugs.python.org (Seth Troisi)
Date: Tue, 24 May 2011 02:27:05 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306204025.92.0.1546388276.issue12162@psf.upfronthosting.co.za>


Seth Troisi <braintwo at gmail.com> added the comment:

Given David Murray's input I think the example would be best done as 

>>> re.search(r'(\w+) \1', "can you do the can can?") # Matches the duplicate can
<_sre.SRE_Match object at ...>


I want to stress that the documentation is not wrong but confusing, especially for someone unfamiliar with regression expressions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12162>
_______________________________________

From report at bugs.python.org  Tue May 24 04:40:36 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 24 May 2011 02:40:36 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306204836.44.0.829428101676.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Ok, so it's 893b098929e7 where that test stops working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue May 24 04:45:08 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 24 May 2011 02:45:08 +0000
Subject: [issue12029] ABC registration of Exceptions
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1306205108.69.0.954360202278.issue12029@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Surveying the docs, the current behavior *is* /technically/ correct (in a suspiciously precise way) according to the Language Reference:
http://docs.python.org/dev/reference/compound_stmts.html#grammar-token-try_stmt :
"For an except clause with an expression [...] the clause matches the exception if the resulting object is 'compatible' with the exception. An object is compatible with an exception if it is the class or a base class of the exception object" (which exactly describes what PyType_IsSubtype() checks for)

The Tutorial is by contrast much more vague:
http://docs.python.org/dev/tutorial/errors.html#handling-exceptions :
"if [the raised exception's] type matches the exception named after the except keyword, the except clause is executed, and then execution continues after the try statement."
No definition of what it means for the types to "match" seems to be given.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Tue May 24 05:29:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2011 03:29:08 +0000
Subject: [issue12163] str.count
In-Reply-To: <1306203026.57.0.880785470377.issue12163@psf.upfronthosting.co.za>
Message-ID: <1306207748.24.0.473364226483.issue12163@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For background on a similar issue, see #11828, especially msg133532.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12163>
_______________________________________

From report at bugs.python.org  Tue May 24 07:12:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 May 2011 05:12:33 +0000
Subject: [issue5405] There is no way of determining which ABCs a class is
	registered against
In-Reply-To: <1235990222.31.0.178922023306.issue5405@psf.upfronthosting.co.za>
Message-ID: <1306213953.39.0.470518703043.issue5405@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This topic came up again on python-ideas:
http://mail.python.org/pipermail/python-ideas/2011-May/010293.html

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5405>
_______________________________________

From report at bugs.python.org  Tue May 24 07:14:45 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 May 2011 05:14:45 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

In Python 2.6 and 2.7, str.translate accepts None as a first argument.  That's documented in the docs, but not in the str.translate docstring.

----------
assignee: docs at python
components: Documentation
messages: 136720
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: str.translate docstring doesn't mention that 'table' can be None
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12164>
_______________________________________

From report at bugs.python.org  Tue May 24 07:43:56 2011
From: report at bugs.python.org (Brian May)
Date: Tue, 24 May 2011 05:43:56 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1306215836.75.0.300504831736.issue6560@psf.upfronthosting.co.za>


Brian May <brian at microcomaustralia.com.au> added the comment:

Hello,

Are there any problems applying the v5 version of the patch to 3.3?

Also is there any remote chance for a backport to 2.7?

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue May 24 07:57:37 2011
From: report at bugs.python.org (Lukas Petru)
Date: Tue, 24 May 2011 05:57:37 +0000
Subject: [issue12165] Does nonlocal include global?
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>


New submission from Lukas Petru <lukas.petru at seznam.cz>:

Can "nonlocal x" declaration also reference global x? I would assume that global scope automatically encloses all other scopes. But the nonlocal keyword seems to exclude global scope. This seems counter-intuitive. (maybe bug in implementation?)

For example:

x=0

def count(i):
    nonlocal x; x+=i; return x;

Checking this code in IDLE gives: no binding for nonlocal 'x' found. If this is what was intended, maybe it should be more clearly written in the documentation.

I am coming to Python from Lisp, so I am still learning Python's principles.

----------
components: Interpreter Core
messages: 136722
nosy: Lukas.Petru
priority: normal
severity: normal
status: open
title: Does nonlocal include global?
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Tue May 24 08:10:36 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 24 May 2011 06:10:36 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306217436.33.0.378403794058.issue1625@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Wait, the tests seem wrong. I'll post an update later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Tue May 24 08:11:17 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 24 May 2011 06:11:17 +0000
Subject: [issue12136] test_logging fails when no ssl available
In-Reply-To: <1305992468.22.0.0355418363055.issue12136@psf.upfronthosting.co.za>
Message-ID: <1306217477.61.0.42826924119.issue12136@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12136>
_______________________________________

From report at bugs.python.org  Tue May 24 08:11:48 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 24 May 2011 06:11:48 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1306217508.89.0.124400723335.issue12151@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Tue May 24 08:53:39 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 24 May 2011 06:53:39 +0000
Subject: [issue8796] Deprecate codecs.open(),
	codecs.StreamReader and codecs.StreamWriter
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306220019.84.0.483948347638.issue8796@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/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 24 09:32:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 07:32:37 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1306222357.13.0.382806629523.issue12155@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is it unclear to you what those mean?

Well, it's clear, but I like when I can simply copy/paste the example and it does just work:

> If you post a high-quality self-contained example somewhere 
> on the net, I would be happy to link to it.

I just propose to change the example to stop the threads:
------------------
def worker():
    while True:
        item = q.get()
        if item is None:
            break
        do_work(item)
        q.task_done()

q = Queue()
threads = []
for i in range(num_worker_threads):
     t = Thread(target=worker)
     threads.append(t)
     t.start()

for item in source():
    q.put(item)

q.join()       # block until all tasks are done
for i in range(num_worker_threads):
    q.put(None)
for t in threads: t.join()
------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Tue May 24 09:35:23 2011
From: report at bugs.python.org (=?utf-8?q?Gergely_K=C3=A1lm=C3=A1n?=)
Date: Tue, 24 May 2011 07:35:23 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <20110523185628.GA2978@dbwatson.ukfsn.org>
Message-ID: <4DDB5FB7.5020909@duodecad.hu>


Gergely K?lm?n <kalman.gergely at duodecad.hu> added the comment:

No, indeed this is a lot better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue May 24 09:41:45 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 24 May 2011 07:41:45 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <1306222905.43.0.464737740366.issue8796@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
title: Deprecate codecs.open(),	codecs.StreamReader and codecs.StreamWriter -> Deprecate codecs.open()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Tue May 24 11:23:51 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 24 May 2011 09:23:51 +0000
Subject: [issue12166] object.__dir__
In-Reply-To: <1306229031.01.0.0272931963515.issue12166@psf.upfronthosting.co.za>
Message-ID: <1306229031.01.0.0272931963515.issue12166@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Implementing a custom __dir__ method is fiddly because there is no way of obtaining the standard list of attributes that dir would return.

Moving the relevant parts of the dir implementation into object.__dir__ would allow a custom __dir__ to obtain the "standard list" by calling up to the base class.

See email discussion at:

http://mail.python.org/pipermail/python-ideas/2011-May/010319.html

----------
messages: 136726
nosy: benjamin.peterson, michael.foord
priority: normal
severity: normal
status: open
title: object.__dir__
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12166>
_______________________________________

From report at bugs.python.org  Tue May 24 11:55:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 09:55:36 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec at
	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1306230936.31.0.10674441717.issue12100@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I think it's better to use a StringIO instance for the tests.

For which test excatly? An encoder produces bytes, I don't the relation with StringIO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Tue May 24 12:05:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 10:05:21 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <E1QOoUJ-0002Q0-Iy@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5c716437a83a by Victor Stinner in branch 'default':
Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl
http://hg.python.org/cpython/rev/5c716437a83a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Tue May 24 12:05:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 10:05:38 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <1306231538.39.0.966756301965.issue12049@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/issue12049>
_______________________________________

From report at bugs.python.org  Tue May 24 12:07:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 10:07:26 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Looks like either packaging or test_packaging forgets to clean up after itself:

results for 9a16fa0c9548 on branch "default"
--------------------------------------------

test_packaging leaked [193, 193, 193] references, sum=579

----------
assignee: tarek
components: Distutils2, Tests
messages: 136729
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_packaging reference leak
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 12:17:16 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 24 May 2011 10:17:16 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1306230936.31.0.10674441717.issue12100@psf.upfronthosting.co.za>
Message-ID: <4DDB85A8.8020006@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> I think it's better to use a StringIO instance for the tests.
> 
> For which test excatly? An encoder produces bytes, I don't the relation with StringIO.

Sorry, BytesIO in Python3-speak. In Python2 you'd use StringIO.

----------
title: Incremental encoders of CJK codecs reset the codec at each call to encode() -> Incremental encoders of CJK codecs reset the codec at	each call to encode()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Tue May 24 12:25:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 10:25:44 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc or make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <1306232744.28.0.51296155895.issue12028@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

threading_get_ident.patch: make get_ident() public, replace threading._get_ident() by threading.get_ident().

According to this patch, get_ident() function *is* used: it is used by the logging and reprlib modules (and many tests). My patch avoids the usage of the low-level module, _thread_, in logging and reprlib.

I adapted signal.pthread_kill() documentation to replace threading.current_thread().ident by threading.get_ident().

----------
keywords: +patch
Added file: http://bugs.python.org/file22089/threading_get_ident.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Tue May 24 12:53:30 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 24 May 2011 10:53:30 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306234410.26.0.688758038651.issue12167@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/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 12:53:44 2011
From: report at bugs.python.org (Philip Drew)
Date: Tue, 24 May 2011 10:53:44 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306234424.96.0.225324067571.issue12140@psf.upfronthosting.co.za>


Philip Drew <pwtdrew at gmail.com> added the comment:

Ok, python now works in command prompt, but IDLE still wont run.
Also, PYTHONHOME needs to be reset on every start up of command prompt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Tue May 24 12:53:55 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 24 May 2011 10:53:55 +0000
Subject: [issue12166] object.__dir__
In-Reply-To: <1306229031.01.0.0272931963515.issue12166@psf.upfronthosting.co.za>
Message-ID: <1306234435.31.0.0770220747925.issue12166@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/issue12166>
_______________________________________

From report at bugs.python.org  Tue May 24 12:55:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 10:55:14 +0000
Subject: [issue12089] regrtest.py doesn't check for unexpected output anymore?
In-Reply-To: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>
Message-ID: <1306234514.46.0.444332638434.issue12089@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Antoine: What's your opinion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12089>
_______________________________________

From report at bugs.python.org  Tue May 24 12:58:33 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 24 May 2011 10:58:33 +0000
Subject: [issue11748] test_ftplib failure in test for source_address
In-Reply-To: <1301846814.75.0.746123609794.issue11748@psf.upfronthosting.co.za>
Message-ID: <1306234713.42.0.42976847992.issue11748@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Is this fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11748>
_______________________________________

From report at bugs.python.org  Tue May 24 12:59:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 10:59:23 +0000
Subject: [issue12089] regrtest.py doesn't check for unexpected output anymore?
In-Reply-To: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>
Message-ID: <1306234763.59.0.33275346755.issue12089@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

IMO this was all obsolete long ago, when we replaced stdout-based comparison of test results with proper assert* method calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12089>
_______________________________________

From report at bugs.python.org  Tue May 24 13:03:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 24 May 2011 11:03:35 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306235015.68.0.691468834505.issue12140@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, this is probably a system-wide setting. PYTHONHOME should not be set, especially if it points to another python installation.
You should consider removing it.

Is "alien swarm" a game? Why did it modify the system this way? Does the game still work when you remove the environment variable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Tue May 24 13:23:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 24 May 2011 11:23:17 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306236197.57.0.23606868161.issue12167@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Probably because new extension modules are built and imported on every run.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 13:26:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 11:26:18 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306236197.57.0.23606868161.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306236375.3493.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Probably because new extension modules are built and imported on every run.

Well, test_distutils does the same, doesn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 13:28:54 2011
From: report at bugs.python.org (Philip Drew)
Date: Tue, 24 May 2011 11:28:54 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306236534.03.0.390760911126.issue12140@psf.upfronthosting.co.za>


Philip Drew <pwtdrew at gmail.com> added the comment:

Awesome. It's fixed- do you still want to know whether or not the game works.
In case it helps, I installed the game before python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Tue May 24 13:32:44 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 24 May 2011 11:32:44 +0000
Subject: [issue12140] Crash upon start up
In-Reply-To: <1306016395.52.0.51170068048.issue12140@psf.upfronthosting.co.za>
Message-ID: <1306236764.2.0.709724130191.issue12140@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's definitely a bad thing to set PYTHONHOME at the system level, when there are several pythons installed. Please report this to the game's developers.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12140>
_______________________________________

From report at bugs.python.org  Tue May 24 13:37:42 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 24 May 2011 11:37:42 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306237062.34.0.881126821444.issue12167@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I could not find any test in distutils/tests that imports extension modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 13:41:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 11:41:04 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306237264.13.0.881449804711.issue12167@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

DistributionTestCase.test_hooks_get_run() leaks some references, I'm trying to understand where exactly.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 13:44:13 2011
From: report at bugs.python.org (Carl Crowder)
Date: Tue, 24 May 2011 11:44:13 +0000
Subject: [issue12168] SysLogHandler incorrectly appents \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>


New submission from Carl Crowder <carl.crowder at gmail.com>:

logging.handlers.SysLogHandler contains this class variable and comment:

    # curious: when talking to the unix-domain '/dev/log' socket, a
    # zero-terminator seems to be required.  this string is placed
    # into a class variable so that it can be overridden if
    # necessary.
    log_format_string = '<%d>%s\000'

And separately, in emit:

    msg = self.format(record) + '\000'

The assumption here is that a null character must be appended to delimit the syslog message. In RFC5424, there is no mention of a message delimiter, and in fact the previous syslog RFC, RFC3164, specifically states:

>  The MSG part will fill the remainder of the syslog packet.  This will usually contain some additional information of the process that generated the message, and then the text of the message.  There is no ending delimiter to this part.

I believe this comment and behaviour is due to an older version of syslogd. Checking the manpage for an older version of rsyslog for example includes this piece of information [1]:

> There is probably one important consideration when installing rsyslogd. It is dependent on proper formatting of messages by the syslog function. The functioning of the syslog function in the shared libraries changed somewhere in the region of libc.so.4.[2-4].n.   The specific change was to null-terminate the message before transmitting it to the /dev/log socket. Proper functioning of this  version of rsyslogd is dependent on null-termination of the message.

I'm running Ubuntu 11.04 with rsyslogd 4.6.4 (that is, the standard version). In the manpage for this version of rsyslogd, there is no reference to null-terminators. Removing "+ '\000'" from the SysLogHandler results in messages still being received correctly.

Problem behaviour:
1) When running any RFC compliant syslog receiver that handles syslog messages, such as flume[2], this null character is not stripped as it is not expected to be present. Current versions of syslog cope because previously they assumed it existed.
2) The log_format_string class variable is not actually used anywhere, so it cannot be overridden usefully.

Removing the null terminator will cause older typical versions of syslogd to fail to receive messages, however including it causes any normal receiver that does not implement the non-standard behaviour to receive an additional unwanted null.

Suggestion for a fix is either to properly use the log_format_string class variable, or to allow an optional "append_null" argument to the SysLogHandler constructor. By default, this should be True, as it will continue to work with the main use case, which is unix syslog demons. Having the option will allow other use cases to also use the SysLogHandler.

[1] http://manpages.ubuntu.com/manpages/hardy/man8/rsyslogd.8.html#contenttoc8
[2] http://www.cloudera.com/blog/category/flume/

----------
components: Library (Lib)
messages: 136743
nosy: Carl.Crowder
priority: normal
severity: normal
status: open
title: SysLogHandler incorrectly appents \000 to messages
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Tue May 24 13:47:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 11:47:50 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306237670.39.0.818336481408.issue12167@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Let's see:

-> test_command_bdist_dumb.py leaks:
test_packaging leaked [7, 7] references, sum=14

-> test_dist.py leaks:
test_packaging leaked [65, 65] references, sum=130

-> test_mixin2to3.py leaks:
test_packaging leaked [60, 60] references, sum=120

-> test_pypi_dist.py leaks:
test_packaging leaked [28, 28] references, sum=56

-> test_pypi_simple.py leaks:
test_packaging leaked [12, 12] references, sum=24

-> test_uninstall.py leaks:
test_packaging leaked [5, 5] references, sum=10

-> test_util.py leaks:
test_packaging leaked [40, 40] references, sum=80

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 14:01:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 12:01:54 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <E1QOqJ5-0003j0-JA@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 70675864717b by Victor Stinner in branch 'default':
Issue #12167: packaging.tests.support, LoggingCatcher restores correctly the
http://hg.python.org/cpython/rev/70675864717b

New changeset 28c1f8480090 by Victor Stinner in branch 'default':
Issue #12167: packaging.tests.test_dist unloads the temporary module
http://hg.python.org/cpython/rev/28c1f8480090

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 14:03:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 12:03:33 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306238613.15.0.304822566685.issue12167@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In test_command_bdist, the leak is in test_simple_built().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 14:06:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 12:06:43 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306238803.21.0.0306776376522.issue12167@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In test_mixin2to3.py, the leak is shared between the 3 test methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 14:09:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 12:09:10 +0000
Subject: [issue12167] test_packaging reference leak
In-Reply-To: <1306231646.32.0.292171987241.issue12167@psf.upfronthosting.co.za>
Message-ID: <1306238950.82.0.737137021018.issue12167@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

In test_pypi_dist, the leak is shared between test_download() and test_unpack().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12167>
_______________________________________

From report at bugs.python.org  Tue May 24 15:15:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 13:15:30 +0000
Subject: [issue12070] Unlimited loop in sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <1306242930.76.0.670999139945.issue12070@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

distutils.sysconfig has also a parse_makefile() function, but it doesn't have the bug.

Attached patch fixes this issue: keep "bogus" variables unchanged and adds tests for _parse_makefile().

----------
keywords: +patch
versions: +Python 3.2
Added file: http://bugs.python.org/file22090/sysconfig.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12070>
_______________________________________

From report at bugs.python.org  Tue May 24 16:16:42 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 24 May 2011 14:16:42 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306246602.66.0.900659518814.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Correction for msg136711 -- s/patch/test/g

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Tue May 24 16:27:13 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Tue, 24 May 2011 14:27:13 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1306247233.27.0.591822496855.issue12113@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Same here, cannot reproduce the issue. I wasn't able to reproduce it even before Tarek's commit so I suppose his commit didnt changed anything regarding this hash problem.

Antoine & Tarek, does the attached additional test reproduces the issue on your installation?

----------
assignee: tarek -> alexis
keywords: +patch
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file22091/serve_twice.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Tue May 24 16:38:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 14:38:39 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1306247919.6.0.395764318655.issue12113@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/issue12113>
_______________________________________

From report at bugs.python.org  Tue May 24 16:39:37 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 24 May 2011 14:39:37 +0000
Subject: [issue12113] test_packaging fails when run twice
In-Reply-To: <1305806981.74.0.68791744955.issue12113@psf.upfronthosting.co.za>
Message-ID: <1306247977.38.0.760967635539.issue12113@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I fixed it. The pypi server missed a Content-Length in its responses, and that made urlretrieve crazy :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12113>
_______________________________________

From report at bugs.python.org  Tue May 24 16:49:59 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 24 May 2011 14:49:59 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306248599.76.0.423031215739.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

OK, I'll hold off on doing a detailed review until then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Tue May 24 17:17:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 15:17:34 +0000
Subject: [issue11998] test_signal cannot test blocked signals if _tkinter is
	loaded; Tcl_Finalize()
In-Reply-To: <1304505040.09.0.715253576105.issue11998@psf.upfronthosting.co.za>
Message-ID: <1306250254.1.0.893719037019.issue11998@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I implemented signal.pthread_kill(), so it's now possible to test pending signals in test_signal, even if _tkinter is loaded.

I don't think that we need the _finalize() hack anymore.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11998>
_______________________________________

From report at bugs.python.org  Tue May 24 17:48:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 24 May 2011 15:48:27 +0000
Subject: [issue11512] adding test suite for cgitb
In-Reply-To: <1300143894.4.0.405606166364.issue11512@psf.upfronthosting.co.za>
Message-ID: <1306252107.89.0.800589957956.issue11512@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/issue11512>
_______________________________________

From report at bugs.python.org  Tue May 24 17:53:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 15:53:44 +0000
Subject: [issue11242] urllib.request.url_open() doesn't support SSLContext
In-Reply-To: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za>
Message-ID: <1306252424.72.0.233166471182.issue11242@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

url_open_ssl_context.patch: add optinal ssl_context argument to urllib.request.url_open(). (ca_file, ca_path) and ssl_context are mutual exclusive.

----------
keywords: +patch
Added file: http://bugs.python.org/file22092/url_open_ssl_context.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11242>
_______________________________________

From report at bugs.python.org  Tue May 24 17:56:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 May 2011 15:56:51 +0000
Subject: [issue11242] urllib.request.url_open() doesn't support SSLContext
In-Reply-To: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za>
Message-ID: <1306252611.94.0.00175309377676.issue11242@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's not really useful. If you want to use an SSL context, build your own opener:

opener = build_opener(HTTPSHandler(context=mycontext))
opener.open(...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11242>
_______________________________________

From report at bugs.python.org  Tue May 24 18:00:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:00:11 +0000
Subject: [issue12055] doctest not working on nested functions
In-Reply-To: <1305115001.62.0.325361690739.issue12055@psf.upfronthosting.co.za>
Message-ID: <1306252811.61.0.737940445568.issue12055@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

2.7 and 3.2 are the present, but we work for the future :)  Thanks for the patch.

I?m adding to the nosy list the developers who committed the most recent changes to doctest so that someone can decide whether this new feature is desirable and review the patch.

----------
keywords: +needs review
nosy: +flox, georg.brandl, ncoghlan
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12055>
_______________________________________

From report at bugs.python.org  Tue May 24 18:09:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 16:09:00 +0000
Subject: [issue12166] object.__dir__
In-Reply-To: <1306229031.01.0.0272931963515.issue12166@psf.upfronthosting.co.za>
Message-ID: <E1QOuAE-0002z7-1b@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8f403199f999 by Benjamin Peterson in branch 'default':
move specialized dir implementations into __dir__ methods (closes #12166)
http://hg.python.org/cpython/rev/8f403199f999

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12166>
_______________________________________

From report at bugs.python.org  Tue May 24 18:11:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 24 May 2011 16:11:21 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1306253481.55.0.332173223944.issue12105@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Checking the kernel version did the trick, the test now run fines on the buildbots.
Thanks Victor.
Re-closing.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12105>
_______________________________________

From report at bugs.python.org  Tue May 24 18:12:16 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 24 May 2011 16:12:16 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1306253536.92.0.914901001629.issue11109@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Justin,

The patch and logic is okay. We can have this is 3.3.

- I find that loop_actions as not appropriate name for the new method. It fails to give a intuitive meaning of what is supposed to do. request_action, request_action_continued or anything else which gives a meaning should be helpful.  I agree with your reasoning to provide some flexiblity for the user to override this.

- The patch lacks Documentation and tests should be added to Lib/test/test_socketserver.py.  If you can, please append the patch with these, otherwise I shall do it.

A suggestion for better method name is a must! :)

Thanks!

----------
assignee: gregory.p.smith -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Tue May 24 18:15:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 24 May 2011 16:15:34 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1306253734.45.0.8995933911.issue8407@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> New changeset f8c49a930015 by Victor Stinner in branch 'default':
> Issue #8407: The signal handler writes the signal number as a single byte
> http://hg.python.org/cpython/rev/f8c49a930015

There's a race.
If a signal is received while is_tripped is set, the signal number won't be written to the wakeup FD.
Patch attached.

----------
Added file: http://bugs.python.org/file22093/sig_wakeup_race.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Tue May 24 18:23:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 16:23:33 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <E1QOuOJ-0004Cx-RP@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f13c06b777a7 by Charles-Fran?ois Natali in branch '3.1':
Issue #5715: In socketserver, close the server socket in the child process.
http://hg.python.org/cpython/rev/f13c06b777a7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 18:27:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 16:27:58 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <E1QOuSb-0004de-JS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ccd59ba8145e by Charles-Fran?ois Natali in branch '3.2':
Issue #5715: In socketserver, close the server socket in the child process.
http://hg.python.org/cpython/rev/ccd59ba8145e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 18:28:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2011 16:28:58 +0000
Subject: [issue11512] adding test suite for cgitb
In-Reply-To: <1300143894.4.0.405606166364.issue11512@psf.upfronthosting.co.za>
Message-ID: <1306254538.27.0.0228808200677.issue11512@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/issue11512>
_______________________________________

From report at bugs.python.org  Tue May 24 18:29:21 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 24 May 2011 16:29:21 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306254561.82.0.906223883425.issue8898@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

After discussing on IRC, it figured out that the best choice would be to use normalize_encoding plus ALIAS, as the attached patch does.

----------
Added file: http://bugs.python.org/file22094/issue8898_normalize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Tue May 24 18:30:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 16:30:27 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <E1QOuUz-0004xV-TM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0e56d79fa2ab by Charles-Fran?ois Natali in branch 'default':
Issue #5715: In socketserver, close the server socket in the child process.
http://hg.python.org/cpython/rev/0e56d79fa2ab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 18:31:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:31:01 +0000
Subject: [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <1306254661.14.0.811273702387.issue12160@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12160>
_______________________________________

From report at bugs.python.org  Tue May 24 18:34:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:34:51 +0000
Subject: [issue12165] Does nonlocal include global?
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1306254891.27.0.385952788508.issue12165@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does this doc help: http://docs.python.org/dev/reference/simple_stmts#the-nonlocal-statement ?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Tue May 24 18:35:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:35:24 +0000
Subject: [issue12168] SysLogHandler incorrectly appents \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306254924.51.0.335547717275.issue12168@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Tue May 24 18:37:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2011 16:37:01 +0000
Subject: [issue12168] SysLogHandler incorrectly appents \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306255021.66.0.538051523051.issue12168@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

While I agree that it should ideally be possible to actually control this behavior as indicated by the comment, any syslog handler that does not sanitize the messages it receives is broken.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Tue May 24 18:38:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2011 16:38:13 +0000
Subject: [issue12168] SysLogHandler incorrectly appents \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306255093.92.0.798818617752.issue12168@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

s/handler/receiver/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Tue May 24 18:41:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:41:29 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1306255289.76.0.735026106778.issue11921@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The PEP has been edited to add python_implementation to the list of environment markers tokens.  Now the code needs a patch to allow using markers in the extensions section.

----------
title: distutils2 should be able to compile an Extension based	on the Python implementation version -> distutils2 should be able to compile an Extension based on the Python implementation
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11921>
_______________________________________

From report at bugs.python.org  Tue May 24 18:41:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:41:50 +0000
Subject: [issue11880] add a {dist-info} category to distutils2
In-Reply-To: <1303231865.42.0.936595329467.issue11880@psf.upfronthosting.co.za>
Message-ID: <1306255310.2.0.592033581115.issue11880@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11880>
_______________________________________

From report at bugs.python.org  Tue May 24 18:48:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 May 2011 16:48:45 +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: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

These three commands have different code to do POST requests, using rllib or httplib.  This already made us do more work to fix bugs and to port the code.  upload_docs has a top-level function for multipart encoding; this should be moved to a common module, cleaned up and used by all our code that needs a POST.

----------
assignee: tarek
components: Distutils2
messages: 136770
nosy: alexis, eric.araujo, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Factor out common code for d2 commands register, upload and upload_docs
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Tue May 24 19:06:35 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 24 May 2011 17:06:35 +0000
Subject: [issue12168] SysLogHandler incorrectly appents \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306256795.63.0.0227189932814.issue12168@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Even though expecting the NUL-terminator is legacy behaviour, newer versions of the syslog daemons presumably follow Postel's rule of "be conservative in what you do, be liberal in what you accept from others". Can flume not be changed to follow this principle, given that ordinarily you wouldn't expect a NUL terminator byte on syslog messages?

When the implementation of SysLogHandler was changed to comply (more closely) with RFC5424, the log_format_string value was inadvertently left behind in Python 2.x, and it makes sense to remove it since changing it doesn't do anything useful.

Having an append_nul parameter to control NUL-termination is certainly doable, and this approach will keep the 2.x and 3.x implementations more or less the same (as 3.x doesn't have a log_format_string attribute). I suggest "nul" rather than "null" since we're talking about appending a NUL byte to the message.

However, having it as an additional keyword parameter to the constructor could cause dictConfig failures if configurations specifying it are used with an old version of Python (e.g. 3.2.0) which doesn't have the parameter. For this reason, it might be better to have an append_nul class attribute (defaulting to True) which can be overridden with an instance attribute set to False. (This approach can still be used with dictConfig, as you can use a factory function other than the SysLogHandler class to construct a SysLogHandler instance.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Tue May 24 19:07:25 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 24 May 2011 17:07:25 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306256845.7.0.708593307057.issue3754@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Greg, ensure correct configure script first as run commands autoheader and autoconf.
Updates to configure script are not in patch . The patch include updates to source configure.in and autoconf command will update "configure".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Tue May 24 19:25:58 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 May 2011 17:25:58 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306257958.75.0.852377581377.issue5715@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You change caused test_socketserver to hang. I attempted a fix, but I'm not sure if it's completely correct.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 19:44:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 24 May 2011 17:44:32 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306259072.9.0.765413481894.issue5715@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> You change caused test_socketserver to hang. I attempted a fix, but I'm not sure if it's completely correct.

I'm a morron.
I don't know how I could miss this: closing the server socket is perfectly fine in TCP, since a new one is returned by accept(). But in UDP, it's definitely wrong, since it's used by the handler.
I don't know however how I missed this, since I remember having run test_socketserver...

The best fix is simply to revert the patch.
I'm really sorry about this...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 19:47:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 24 May 2011 17:47:31 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306259251.2.0.852504311713.issue5715@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22045/ss_fork_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 19:51:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 17:51:26 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <E1QOvlM-0003xS-OV@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3e1709213532 by Benjamin Peterson in branch '3.1':
backout 8b384de4e780, so a proper fix can be considered (#5715)
http://hg.python.org/cpython/rev/3e1709213532

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 19:51:45 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 May 2011 17:51:45 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1306259072.9.0.765413481894.issue5715@psf.upfronthosting.co.za>
Message-ID: <BANLkTikStr6OD2vhwS1fa5F0tDBgM32xCw@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/24 Charles-Fran?ois Natali <report at bugs.python.org>:
>
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
>
>> You change caused test_socketserver to hang. I attempted a fix, but I'm not sure if it's completely correct.
>
> I'm a morron.
> I don't know how I could miss this: closing the server socket is perfectly fine in TCP, since a new one is returned by accept(). But in UDP, it's definitely wrong, since it's used by the handler.
> I don't know however how I missed this, since I remember having run test_socketserver...
>
> The best fix is simply to revert the patch.

Done.

> I'm really sorry about this...

Don't worry. It's a bit of a rite of passage for new developers to
break the buildbots. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 20:13:36 2011
From: report at bugs.python.org (Martin)
Date: Tue, 24 May 2011 18:13:36 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1306260816.41.0.391320819132.issue12100@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

Does Victor Stinner have a psychic link with Armin Rigo? :)

https://bitbucket.org/pypy/pypy/src/7f593e7877d4/pypy/module/_multibytecodec/app_multibytecodec.py

"""
# My theory is that they are not widely used on CPython either, because
# I found two bugs just by looking at their .c source: they always call
# encreset() after a piece of data, even though I think it's wrong ---
# it should be called only once at the end; and mbiencoder_reset() calls
# decreset() instead of encreset().
"""

The answer to Armin's theory is that they're bugs but not ones users are likely to notice?

----------
nosy: +arigo, gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Tue May 24 20:59:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 18:59:00 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1239064250.04.0.401358738839.issue5715@psf.upfronthosting.co.za>
Message-ID: <1306263540.56.0.735948466471.issue5715@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It's a bit of a rite of passage for new developers to
> break the buildbots. :)

How long is this rite?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 21:04:06 2011
From: report at bugs.python.org (JJeffries)
Date: Tue, 24 May 2011 19:04:06 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306263846.26.0.262328014381.issue12154@psf.upfronthosting.co.za>


JJeffries <jamesjeffries1 at gmail.com> added the comment:

If it is changed to use inspect.getfullargspec is it still ok to use inspect.formatargspec? I cant work which values returned by getfullargspec need to go into which parameters for formatargspec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12154>
_______________________________________

From report at bugs.python.org  Tue May 24 21:04:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 19:04:15 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1306260816.41.0.391320819132.issue12100@psf.upfronthosting.co.za>
Message-ID: <1306263849.24807.1.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mardi 24 mai 2011 ? 18:13 +0000, Martin a ?crit :
> Martin <gzlist at googlemail.com> added the comment:
> 
> Does Victor Stinner have a psychic link with Armin Rigo? :)
> 
> https://bitbucket.org/pypy/pypy/src/7f593e7877d4/pypy/module/_multibytecodec/app_multibytecodec.py
> 
> """
> # My theory is that they are not widely used on CPython either, because
> # I found two bugs just by looking at their .c source

Sorry, I only found one bug, and while testing HZ, not while reading the
source code.

> ... and mbiencoder_reset() calls decreset() instead of encreset()

This is a new bug that you should be fixed. Armin did not reported the
bug upstream (in this bug tracker)?

> The answer to Armin's theory is that they're bugs but not ones users are likely to notice?

Ok, I will apply my fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Tue May 24 21:04:27 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 May 2011 19:04:27 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1306263540.56.0.735948466471.issue5715@psf.upfronthosting.co.za>
Message-ID: <BANLkTin-LOGL+e6nY12VTbizcMajUBjMqw@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/24 STINNER Victor <report at bugs.python.org>:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> It's a bit of a rite of passage for new developers to
>> break the buildbots. :)
>
> How long is this rite?

The approximate number of times you do it each year is e^(-x) + C where C >= 13.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________

From report at bugs.python.org  Tue May 24 21:08:02 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 24 May 2011 19:08:02 +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: <1306264082.42.0.298339484736.issue12169@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

good idea! want to tackle this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Tue May 24 21:26:49 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 24 May 2011 19:26:49 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <20110524192633.GA84457@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Hello, David, i'm about to remind you that this issue is still
open (and the next release is about to come soon).
I think we do agree at least in the fact that this is a bug :).
Well, your mailbox_close_twice.patch no. 2 still imports on the
current tip.

(I'm still a bit disappointed that you don't want to -a-r-m-
upgrade the proxies to the full implementation i've posted.  But
it's ok.  By the way: you're the first american i know who doesn't
want to upgrade his arms!  And i do have had an ex-uncle who is
a fellow countryman of yours.)

Regards from Germany during kitschy pink sunset

----------
Added file: http://bugs.python.org/file22095/11700.yeah-review.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________
-------------- next part --------------
diff --git a/Lib/mailbox.py b/Lib/mailbox.py
--- a/Lib/mailbox.py
+++ b/Lib/mailbox.py
@@ -1864,97 +1864,142 @@
     """Message with MMDF-specific properties."""
 
 
-class _ProxyFile:
-    """A read-only wrapper of a file."""
+class _ProxyFile(io.BufferedIOBase):
+    """A io.BufferedIOBase inheriting read-only wrapper for a seekable file.
+    It supports __iter__() and the context-manager protocol.
+    """
+    def __init__(self, file, pos=None):
+        io.BufferedIOBase.__init__(self)
+        self._file = file
+        self._pos = file.tell() if pos is None else pos
+        self._close = True
+        self._is_open = True
 
-    def __init__(self, f, pos=None):
-        """Initialize a _ProxyFile."""
-        self._file = f
-        if pos is None:
-            self._pos = f.tell()
+    def _set_noclose(self):
+        """Subclass hook - use to avoid closing internal file object."""
+        self._close = False
+
+    def _closed_check(self):
+        """Raise ValueError if not open."""
+        if not self._is_open:
+            raise ValueError('I/O operation on closed file')
+
+    def close(self):
+        if self._close:
+            self._close = False
+            self._file.close()
+            del self._file
+        self._is_open = False
+
+    @property
+    def closed(self):
+        return not self._is_open
+
+    def flush(self):
+        # Not possible because it gets falsely called (issue 11700)
+        #raise io.UnsupportedOperation('flush')
+        pass
+
+    def _read(self, size, read_method, readinto_arg=None):
+        if size is None or size < 0:
+            size = -1
+        self._file.seek(self._pos)
+        if not readinto_arg:
+            result = read_method(size)
         else:
-            self._pos = pos
+            result = read_method(readinto_arg)
+            if result < len(readinto_arg):
+                del readinto_arg[result:]
+        self._pos = self._file.tell()
+        return result
 
-    def read(self, size=None):
-        """Read bytes."""
+    def readable(self):
+        self._closed_check()
+        return True
+
+    def read(self, size=-1):
+        self._closed_check()
+        if size is None or size < 0:
+            return self.readall()
         return self._read(size, self._file.read)
 
-    def read1(self, size=None):
-        """Read bytes."""
+    def read1(self, size=-1):
+        self._closed_check()
+        if size is None or size < 0:
+            return b''
         return self._read(size, self._file.read1)
 
-    def readline(self, size=None):
-        """Read a line."""
+    def readinto(self, by_arr):
+        self._closed_check()
+        return self._read(len(by_arr), self._file.readinto, by_arr)
+
+    def readall(self):
+        self._closed_check()
+        self._file.seek(self._pos)
+        if hasattr(self._file, 'readall'):
+            result = self._file.readall()
+        else:
+            dl = []
+            while 1:
+                i = self._file.read(8192)
+                if len(i) == 0:
+                    break
+                dl.append(i)
+            result = b''.join(dl)
+        self._pos = self._file.tell()
+        return result
+
+    def readline(self, size=-1):
+        self._closed_check()
         return self._read(size, self._file.readline)
 
-    def readlines(self, sizehint=None):
-        """Read multiple lines."""
+    def readlines(self, sizehint=-1):
         result = []
         for line in self:
             result.append(line)
-            if sizehint is not None:
+            if sizehint >= 0:
                 sizehint -= len(line)
                 if sizehint <= 0:
                     break
         return result
 
+    def seekable(self):
+        self._closed_check()
+        return True
+
+    def seek(self, offset, whence=0):
+        self._closed_check()
+        if whence == 1:
+            self._file.seek(self._pos)
+        self._pos = self._file.seek(offset, whence)
+        return self._pos
+
+    def tell(self):
+        self._closed_check()
+        return self._pos
+
+    def writable(self):
+        self._closed_check()
+        return False
+
+    def writelines(self, lines):
+        raise io.UnsupportedOperation('writelines')
+
+    def write(self, b):
+        raise io.UnsupportedOperation('write')
+
     def __iter__(self):
-        """Iterate over lines."""
         while True:
             line = self.readline()
             if not line:
                 raise StopIteration
             yield line
 
-    def tell(self):
-        """Return the position."""
-        return self._pos
-
-    def seek(self, offset, whence=0):
-        """Change position."""
-        if whence == 1:
-            self._file.seek(self._pos)
-        self._file.seek(offset, whence)
-        self._pos = self._file.tell()
-
-    def close(self):
-        """Close the file."""
-        if hasattr(self._file, 'close'):
-            self._file.close()
-        del self._file
-
-    def _read(self, size, read_method):
-        """Read size bytes using read_method."""
-        if size is None:
-            size = -1
-        self._file.seek(self._pos)
-        result = read_method(size)
-        self._pos = self._file.tell()
-        return result
-
     def __enter__(self):
-        """Context manager protocol support."""
         return self
-
     def __exit__(self, *exc):
         self.close()
 
-    def readable(self):
-        return self._file.readable()
-
-    def writable(self):
-        return self._file.writable()
-
-    def seekable(self):
-        return self._file.seekable()
-
-    def flush(self):
-        return self._file.flush()
-
-    @property
-    def closed(self):
-        return self._file.closed
-
 
 class _PartialFile(_ProxyFile):
     """A read-only wrapper of part of a file."""
@@ -1962,6 +2007,7 @@
     def __init__(self, f, start=None, stop=None):
         """Initialize a _PartialFile."""
         _ProxyFile.__init__(self, f, start)
+        super()._set_noclose()
         self._start = start
         self._stop = stop
 
@@ -1971,6 +2017,7 @@
 
     def seek(self, offset, whence=0):
         """Change position, possibly with respect to start or stop."""
+        self._closed_check()
         if whence == 0:
             self._pos = self._start
             whence = 1
@@ -1979,20 +2026,23 @@
             whence = 1
         _ProxyFile.seek(self, offset, whence)
 
-    def _read(self, size, read_method):
+    def _read(self, size, read_method, readinto_arg=None):
         """Read size bytes using read_method, honoring start and stop."""
         remaining = self._stop - self._pos
         if remaining <= 0:
             return b''
         if size is None or size < 0 or size > remaining:
             size = remaining
-        return _ProxyFile._read(self, size, read_method)
+        if not not readinto_arg and size < len(readinto_arg):
+            del readinto_arg[size:]
+        return _ProxyFile._read(self, size, read_method, readinto_arg)
 
-    def close(self):
-        # do *not* close the underlying file object for partial files,
-        # since it's global to the mailbox object
-        del self._file
-
+    def readall(self):
+        self._closed_check()
+        remaining = self._stop - self._pos
+        if remaining <= 0:
+            return b''
+        return _ProxyFile._read(self, remaining, self._file.read)
 
 def _lock_file(f, dotlock=True):
     """Lock file f using lockf and dot locking."""
diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -290,12 +290,17 @@
         key1 = self._box.add(_sample_message)
         with self._box.get_file(key0) as file:
             data0 = file.read()
-        with self._box.get_file(key1) as file:
-            data1 = file.read()
+        file1 = self._box.get_file(key1)
+        data1 = file1.read()
         self.assertEqual(data0.decode('ascii').replace(os.linesep, '\n'),
                          self._template % 0)
         self.assertEqual(data1.decode('ascii').replace(os.linesep, '\n'),
                          _sample_message)
+        file1.close()
+        try:
+            file1.close()
+        except:
+            self.fail('.close() doesn\'t handle multiple invocations')
 
     def test_iterkeys(self):
         # Get keys using iterkeys()
@@ -1774,6 +1779,68 @@
         proxy.seek(2)
         self.assertEqual(proxy.read(1000), b'r')
 
+    def _test_read1(self, proxy):
+        # Read by byte
+        proxy.seek(0)
+        self.assertEqual(proxy.read1(3), b'bar')
+        proxy.seek(1)
+        self.assertEqual(proxy.read1(2), b'ar')
+        proxy.seek(0)
+        self.assertEqual(proxy.read1(2), b'ba')
+        proxy.seek(1)
+        self.assertEqual(proxy.read1(-1), b'')
+        self.assertEqual(proxy.read1(None), b'')
+        self.assertEqual(proxy.read1(1000), b'ar')
+
+    def _test_readinto(self, proxy):
+        # Fill in bytearray
+        proxy.seek(0)
+        ba = bytearray(3)
+        self.assertEqual(proxy.readinto(ba), 3)
+        self.assertEqual(ba, b'bar')
+
+        proxy.seek(1)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(0)
+        ba = bytearray(2)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ba')
+
+        proxy.seek(1)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 2)
+        self.assertEqual(ba, b'ar')
+
+        proxy.seek(2)
+        ba = bytearray(1000)
+        self.assertEqual(proxy.readinto(ba), 1)
+        self.assertEqual(ba, b'r')
+
+    def _test_readall(self, proxy):
+        # Read all the data
+        ls = os.linesep.encode()
+        lsl = len(ls)
+
+        proxy.seek(0)
+        x = b'fiesta' + ls + b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6 + lsl)
+        x = b'mexicana' + ls
+        self.assertEqual(proxy.readall(), x)
+
+        proxy.seek(6+3 + lsl)
+        x = b'icana' + ls
+        self.assertEqual(proxy.readall(), x)
+
     def _test_readline(self, proxy):
         # Read by line
         linesep = os.linesep.encode()
@@ -1833,10 +1900,38 @@
         self.assertFalse(proxy.read())
 
     def _test_close(self, proxy):
-        # Close a file
+        self.assertFalse(proxy.closed)
+        # Not possible (see issue 11700 thread)
+        #self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertTrue(proxy.readable())
+        self.assertTrue(proxy.seekable())
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertFalse(proxy.writable())
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
+
         proxy.close()
-        self.assertRaises(AttributeError, lambda: proxy.close())
+        self.assertTrue(proxy.closed)
+        try:
+            proxy.close()
+        except:
+            self.fail('Proxy.close() failure')
 
+        # Not possible (see issue 11700 thread)
+        #self.assertRaises(io.UnsupportedOperation, proxy.flush)
+        self.assertRaises(ValueError, proxy.readable)
+        self.assertRaises(ValueError, proxy.read)
+        self.assertRaises(ValueError, proxy.readinto, bytearray())
+        self.assertRaises(ValueError, proxy.readall)
+        self.assertRaises(ValueError, proxy.readline)
+        self.assertRaises(ValueError, proxy.readlines)
+        self.assertRaises(ValueError, proxy.seekable)
+        self.assertRaises(ValueError, proxy.seek, 0)
+        self.assertRaises(ValueError, proxy.tell)
+        self.assertRaises(io.UnsupportedOperation, proxy.truncate, 0)
+        self.assertRaises(ValueError, proxy.writable)
+        self.assertRaises(io.UnsupportedOperation, proxy.writelines, ['AU'])
+        self.assertRaises(io.UnsupportedOperation, proxy.write, 'AU')
 
 class TestProxyFile(TestProxyFileBase):
 
@@ -1863,6 +1958,19 @@
         self._file.write(b'bar')
         self._test_read(mailbox._ProxyFile(self._file))
 
+    def test_read1(self):
+        self._file.write(b'bar')
+        self._test_read1(mailbox._ProxyFile(self._file))
+
+    def test_readinto(self):
+        self._file.write(b'bar')
+        self._test_readinto(mailbox._ProxyFile(self._file))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        self._file.write(b'fiesta' + ls + b'mexicana' + ls)
+        self._test_readall(mailbox._ProxyFile(self._file))
+
     def test_readline(self):
         self._file.write(bytes('foo%sbar%sfred%sbob' % (os.linesep, os.linesep,
                                                   os.linesep), 'ascii'))
@@ -1886,6 +1994,13 @@
         self._file.write(bytes('foo%sbar%s' % (os.linesep, os.linesep), 'ascii'))
         self._test_close(mailbox._ProxyFile(self._file))
 
+    def test_ctxman(self):
+        self._file.write(b'foo')
+        proxy = mailbox._ProxyFile(self._file)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 class TestPartialFile(TestProxyFileBase):
 
@@ -1909,6 +2024,20 @@
         self._file.write(bytes('***bar***', 'ascii'))
         self._test_read(mailbox._PartialFile(self._file, 3, 6))
 
+    def test_read1(self):
+        self._file.write(bytes('***bar***', 'ascii'))
+        self._test_read1(mailbox._PartialFile(self._file, 3, 6))
+
+    def test_readinto(self):
+        self._file.write(b'***bar***')
+        self._test_readinto(mailbox._PartialFile(self._file, 3, 6))
+
+    def test_readall(self):
+        ls = os.linesep.encode()
+        lsl = len(ls)
+        self._file.write(b'***fiesta' + ls + b'mexicana' + ls + b'***')
+        self._test_readall(mailbox._PartialFile(self._file, 3, 3+14+2*lsl))
+
     def test_readline(self):
         self._file.write(bytes('!!!!!foo%sbar%sfred%sbob!!!!!' %
                          (os.linesep, os.linesep, os.linesep), 'ascii'))
@@ -1937,6 +2066,14 @@
         self._test_close(mailbox._PartialFile(self._file, 1,
                                               6 + 3 * len(os.linesep)))
 
+    def test_ctxman(self):
+        self._file.write(bytes('foo' + os.linesep + 'bar', 'ascii'))
+        pos = self._file.tell()
+        proxy = mailbox._PartialFile(self._file, 2, 5)
+        with proxy as p:
+            pass
+        self.assertTrue(proxy.closed)
+
 
 ## Start: tests from the original module (for backward compatibility).
 

From report at bugs.python.org  Tue May 24 21:28:21 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 24 May 2011 19:28:21 +0000
Subject: [issue11700] mailbox.py proxy updates
In-Reply-To: <1301315190.34.0.276151285444.issue11700@psf.upfronthosting.co.za>
Message-ID: <1306265301.12.0.228094428842.issue11700@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file22095/11700.yeah-review.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11700>
_______________________________________

From report at bugs.python.org  Tue May 24 21:31:17 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 24 May 2011 19:31:17 +0000
Subject: [issue9654] merge PC/getpathp.c into Modules/getpath.c
In-Reply-To: <1282340469.22.0.133345899544.issue9654@psf.upfronthosting.co.za>
Message-ID: <1306265477.6.0.130658128295.issue9654@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

In which cases it goes to PC/getpathp.c? I suppose it's Modules/getpath.c otherwise.

Line 495 on getpathp.c let me guess it's not only for Windows.

----------
nosy: +maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9654>
_______________________________________

From report at bugs.python.org  Tue May 24 21:32:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 19:32:51 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <E1QOxLW-0005K9-9c@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ca92fa2fe5c9 by Victor Stinner in branch 'default':
Issue #12049: improve RAND_bytes() and RAND_pseudo_bytes() documentation
http://hg.python.org/cpython/rev/ca92fa2fe5c9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Tue May 24 21:49:10 2011
From: report at bugs.python.org (Max)
Date: Tue, 24 May 2011 19:49:10 +0000
Subject: [issue12170] Bytes objects do not accept integers to many functions
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>


New submission from Max <max at alleged.net>:

Bytes objects when indexed provide integers, but do not accept them to many functions, making them inconsistent with other sequences.

Basic example:
>>> test = b'012'
>>> n = test[1]
>>> n
49
>>> n in test
True
>>> test.index(n)
TypeError: expected an object with the buffer interface.

It is certainly unusual for n to be in the sequence, but not to be able to find it.  I would expect the result to be 1.  This set of commands with list, strings, tuples, but not bytes objects.

I suspect, from issue #10616, that all the following functions would be affected:
"bytes methods: partition, rpartition, find, index, rfind, rindex, count, translate, replace, startswith, endswith"

It would make more sense to me that instead of only supporting buffer interface objects, they also accept a single integer, and treat it as if it were provided a length-1 bytes object.

The use case I came across this problem was something like this:

Given seq1 and seq2, sequences of the same type:
[seq1.index(x) for x in seq2]

This works for strings, lists, tuples, but not bytes.

----------
components: Interpreter Core
messages: 136786
nosy: max-alleged
priority: normal
severity: normal
status: open
title: Bytes objects do not accept integers to many functions
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Tue May 24 21:50:59 2011
From: report at bugs.python.org (Max)
Date: Tue, 24 May 2011 19:50:59 +0000
Subject: [issue12170] Bytes objects do not accept integers to many functions
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306266659.13.0.74913821074.issue12170@psf.upfronthosting.co.za>


Max <max at alleged.net> added the comment:

"This set of commands with list, strings, tuples, but not bytes objects."
should read
"This set of commands works with list, strings, tuples, but not bytes objects."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Tue May 24 22:08:14 2011
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 24 May 2011 20:08:14 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1306267694.78.0.189046614422.issue12100@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Hi :-)  I did not report the two issues I found so far because I didn't finish the PyPy implementation of CJK yet, and I'm very new to anything related to codecs; additionally I didn't check Python 3.x, as I was just following the 2.7 sources.  Can someone confirm that the two bugs I suspect are really bugs?  And should I open another report to help tracking the 2nd bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Tue May 24 22:19:20 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Tue, 24 May 2011 20:19:20 +0000
Subject: [issue12034] check_GetFinalPathNameByHandle() suboptimal
In-Reply-To: <1304884806.89.0.503663992861.issue12034@psf.upfronthosting.co.za>
Message-ID: <1306268360.07.0.11648811403.issue12034@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

I looked at providing a patch for this issue as an introductory step (this would be my first patch).

But when following the code I discovered that the case that this issue is trying to optimize is never executed in current CPython. In that case, there isn't much value in optimizing it.

More precisely, check_GetFinalPathNameByHandle is called by posix__getfinalpathname which is nt._getfinalpathname in Python code. If the check fails, posix__getfinalpathname throws NotImplmenentedError. But nt._getfinalpathname is only used by ntpath.py which checks the Windows version and only calls nt._getfinalpathname for Vista and higher where the check won't fail.

To me it would make more sense that the nt module has a _getfinalpathname attribute only if it supports the feature instead of always having one that throws NotImplementedError. In that case, ntpath.py would not check the Windows version but the presence of _getfinalpathname in the nt module. Does this seem like a better approach to you, at least theoretically? And if so, is it worth implementing it?

Thanks for any advice.

----------
nosy: +catalin.iacob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12034>
_______________________________________

From report at bugs.python.org  Tue May 24 22:19:48 2011
From: report at bugs.python.org (Nir Aides)
Date: Tue, 24 May 2011 20:19:48 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306268388.53.0.359821176595.issue1625@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

False alarm; go ahead with the review. I took a look too early in the morning before caffeine kicked in.

Note Lib/test/test_bz2.py was directly upgraded from bz2ms.patch.

A note on bz2 behavior: A BZ2Decompressor object is only good for one stream; after that eof is set and it will refuse to continue to the next stream; this seems in line with bzip2 manual:
http://www.bzip.org/1.0.5/bzip2-manual-1.0.5.html#bzDecompress

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Tue May 24 22:24:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 20:24:36 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <E1QOy9b-0001KI-9y@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bd17396895fb by Victor Stinner in branch '3.1':
Issue #12100: Don't reset incremental encoders of CJK codecs at each call to
http://hg.python.org/cpython/rev/bd17396895fb

New changeset 7f2ab2f95a04 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12100: Don't reset incremental encoders of CJK codecs at
http://hg.python.org/cpython/rev/7f2ab2f95a04

New changeset cb9867dab15e by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12100: Don't reset incremental encoders of CJK codecs at
http://hg.python.org/cpython/rev/cb9867dab15e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Tue May 24 22:29:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 20:29:22 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <E1QOyED-0001kB-3i@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e789b4cda872 by Victor Stinner in branch '2.7':
Issue #12100: Don't reset incremental encoders of CJK codecs at each call to
http://hg.python.org/cpython/rev/e789b4cda872

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Tue May 24 23:12:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 21:12:20 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <E1QOytm-0005bX-PG@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 0dee36595699 by Charles-Fran?ois Natali in branch '2.7':
Issue #1441530: In imaplib, use makefile() to wrap the SSL socket to avoid
http://hg.python.org/cpython/rev/0dee36595699

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Tue May 24 23:30:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 21:30:10 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK codecs
	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

HZ and ISO-2022 family codecs may generate an escape sequence at the end of a stream. For example, the HZ codec uses '~{' to switchs from ASCII to GB2312, and '~}' resets the encoding to ASCII. At the end of a stream, the encoding should be reset to ASCII. '\u804a'.encode('hz') returns b'~{AD~}', which is correct.

Incremental encoders generate also the escape sequence if the last call to encode() is done using final=True.

It would be nice to be able to generate the escape sequence without the final flag, because sometimes you don't know which call to encode() is the last one. For example if you write data in a file, you may want to write the escape sequence at the end when the file is closed.

I propose to change the reset() method of incremental encoders: they may return a bytes object to close the stream. For example, the reset() method of the HZ codec may returns b'~}' if the encoder was using GB2312 (if it emited previously b'~{').

So the 3 following code should returns b'~{AD~}':

 * '\u804a'.encode('hz')
 * encoder = codecs.lookup('hz').incrementalencoder(); encoder.encode('\u804a', final=True)
 * encoder = codecs.lookup('hz').incrementalencoder(); encoder.encode('\u804a') + encoder.reset()

For backward compatibility, reset() returns None if there is no pending buffer or any escape sequence.

--

This proposition comes from #12000: Armin Rigo noticed that the reset method of the incremental encoders of CJK codecs calls the decoder reset function. Extract of Modules/cjkcodecs/multibytecodec.c:

static PyObject *
mbiencoder_reset(MultibyteIncrementalEncoderObject *self)
{
    if (self->codec->decreset != NULL &&
        self->codec->decreset(&self->state, self->codec->config) != 0)
        return NULL;
    self->pendingsize = 0;

    Py_RETURN_NONE;
}

I suppose that codec->encreset() is not called here because we need an output buffer, and there is no such buffer. Or it's just a copy-paste failure.

--

I am not sure that it is really useful to emit b'~}' at the end of a HZ stream, but the change is simple and if you don't care of b'~}': just ignore the result of reset() (as everybody does today, so it doesn't hurt).

--

Only HZ and ISO-2022 encodings implement the reset method of their incremental encoder. For example, encodings of the UTF family don't need to emit bytes at reset.

For the maximum length of reset() output: HZ may generates 2 bytes (b'~}') and ISO-2022 may generates 4 bytes (b'\x0F' + b'\x1F(B').

--

See also the issue #12100.

----------
components: Library (Lib), Unicode
files: cjk_reset_result.patch
keywords: patch
messages: 136794
nosy: arigo, gz, haypo, hyeshik.chang, lemburg
priority: normal
severity: normal
status: open
title: Reset method of the incremental encoders of CJK codecs calls the decoder reset function
versions: Python 3.3
Added file: http://bugs.python.org/file22096/cjk_reset_result.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Tue May 24 23:38:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 21:38:26 +0000
Subject: [issue12070] Unlimited loop in sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <E1QOzJ3-0007Y5-I8@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4a7bb2ef636a by Victor Stinner in branch '3.2':
Issue #12070: Fix the Makefile parser of the sysconfig module to handle
http://hg.python.org/cpython/rev/4a7bb2ef636a

New changeset 98ff40ee0106 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12070: Fix the Makefile parser of the sysconfig module to
http://hg.python.org/cpython/rev/98ff40ee0106

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12070>
_______________________________________

From report at bugs.python.org  Tue May 24 23:40:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 21:40:06 +0000
Subject: [issue12070] Unlimited loop in sysconfig._parse_makefile()
In-Reply-To: <1305295099.63.0.694283123417.issue12070@psf.upfronthosting.co.za>
Message-ID: <1306273206.44.0.151365875478.issue12070@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/issue12070>
_______________________________________

From report at bugs.python.org  Tue May 24 23:48:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 24 May 2011 21:48:21 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK codecs
	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <1306273701.0.0.285113776535.issue12171@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Do we need an additional method? It seems that this reset() could also be written encoder.encode('', final=True)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Tue May 24 23:48:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 21:48:47 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <E1QOzT3-0008ME-W5@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 14bb95a8d7ee by Charles-Fran?ois Natali in branch 'default':
Issue #1441530: In imaplib, read the data in one chunk to speed up large
http://hg.python.org/cpython/rev/14bb95a8d7ee

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Tue May 24 23:50:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 21:50:54 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1306273854.79.0.945340292739.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Haypo, since you've created a new directory there are makefile 
> (and PC build file, I think) updates that will need to be made. 

Can you review attached cjkencodings_dir.patch?

> (This should be documented in the dev guide if it isn't already.)

Do you mean that the cjkencodings directory should be documented? (in setup.rst? subdirectories are not listed) Or the process of adding a new directory?

----------
Added file: http://bugs.python.org/file22097/cjkencodings_dir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 00:04:30 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 24 May 2011 22:04:30 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306274670.98.0.449472037294.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> False alarm; go ahead with the review. I took a look too early in the
> morning before caffeine kicked in.

No worries. I know the feeling.

The tests look fine. The bodies of testRead() and testReadMultiStream()
appear to have been swapped, though. I'm guessing testRead() was
supposed to remain unmodified, with testReadMultiStream() testing the
case of streams=5?

For the change to BZ2File._fill_buffer(), I'm not sure that the check
for end-of-file is correct. It seems that if the end of rawblock lines
up with the end of a stream, the mode will be set to EOF even if there
are more streams waiting to be read. Is this possible?

> A note on bz2 behavior: A BZ2Decompressor object is only good for one
> stream; after that eof is set and it will refuse to continue to the
> next stream; this seems in line with bzip2 manual

I think this is the right way to do things. BZ2Decompressor is a low-
level wrapper around the underlying C API -- it should not grow extra
features unnecessarily. Also, certain use-cases might depend on being
able to detect the end of a logical stream; this would not be possible
if BZ2Decompressor were to be changed.

The difference in behaviour from BZ2File and decompress() should probably
be documented, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Wed May 25 00:14:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2011 22:14:24 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1306275264.53.0.600890216909.issue12057@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume and hope David meant the process, as I would have no idea how to add a directory. And David did not seem completely sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 00:17:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 22:17:45 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QOzv6-00023O-Ho@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 10b23f1c8cb6 by Victor Stinner in branch '3.1':
Issue #12057: Add tests for the HZ encoding
http://hg.python.org/cpython/rev/10b23f1c8cb6

New changeset 3368d4a04e52 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12057: Add tests for the HZ encoding
http://hg.python.org/cpython/rev/3368d4a04e52

New changeset 06c44a518d0b by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12057: Add tests for the HZ encoding
http://hg.python.org/cpython/rev/06c44a518d0b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 00:19:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 22:19:34 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QOzwr-00028I-Hk@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3c724c3eaed7 by Victor Stinner in branch '2.7':
Issue #12057: Add tests for the HZ encoding
http://hg.python.org/cpython/rev/3c724c3eaed7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 00:23:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2011 22:23:50 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1306275830.36.0.197606981026.issue12057@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks good to me.  And I meant documenting the process for adding a directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 00:58:15 2011
From: report at bugs.python.org (Donghyun Kim)
Date: Tue, 24 May 2011 22:58:15 +0000
Subject: [issue5715] listen socket close in
	SocketServer.ForkingMixIn.process_request()
In-Reply-To: <1306259072.9.0.765413481894.issue5715@psf.upfronthosting.co.za>
Message-ID: <53866993-793A-45AD-88B4-F8720DEFBD39@gmail.com>


Donghyun Kim <ryan003 at gmail.com> added the comment:

On May 24, 2011, at 12:44 PM, Charles-Fran??ois Natali wrote:

> I don't know how I could miss this: closing the server socket is perfectly fine in TCP, since a new one is returned by accept(). But in UDP, it's definitely wrong, since it's used by the handler.
> I don't know however how I missed this, since I remember having run test_socketserver...

It's been a long time since the issue submitted, anyway, I was cursed to look at only TCP too :-)

I agree that ForkingUDPServer should be supported in SocketServer.py.
(Although users should take care of socket locking for concurrent accesses)

How about using BaseServer(TCPServer).server_close() instead of self.socket.close() in the patch?

As UDPServer has no server_close() method overridden, unlike ForkingTCPServer, ForkingUDPServer seems to have no actual "server" in design.
So, I think we could say that 
- closing TCP listen socket in child process = "server_close()" in child process
- nothing to do on UDP socket in child process = "server_close() but nothing will be done in the method" (b/c BaseServer.server_close() does nothing)

What do you think?

-----
Donghyun Kim
http://www.uryan.net

----------
Added file: http://bugs.python.org/file22098/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5715>
_______________________________________
-------------- next part --------------
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 24, 2011, at 12:44 PM, Charles-Fran??ois Natali wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I don't know how I could miss this: closing the server socket is perfectly fine in TCP, since a new one is returned by accept(). But in UDP, it's definitely wrong, since it's used by the handler.<br>I don't know however how I missed this, since I remember having run test_socketserver...<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>It's been a long time since the issue submitted, anyway, I was cursed to look at only TCP too :-)<br><br>I agree that ForkingUDPServer should be supported in SocketServer.py.<br>(Although users should take care of socket locking for concurrent accesses)<br><br>How about using BaseServer(TCPServer).server_close() instead of self.socket.close() in the patch?<br><br>As UDPServer has no server_close() method overridden, unlike ForkingTCPServer, ForkingUDPServer seems to have no actual "server" in design.<br>So, I think we could say that&nbsp;<br>- closing TCP listen socket in child process = "server_close()" in child process<br>- nothing to do on UDP socket in child process = "server_close() but nothing will be done in the method" (b/c BaseServer.server_close() does nothing)<br><br>What do you think?</div><div><br></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Malgun Gothic'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">-----<br>Donghyun Kim<br><a href="http://www.uryan.net">http://www.uryan.net</a></span>
</div>
<br></body></html>

From report at bugs.python.org  Wed May 25 01:11:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 23:11:40 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1306278700.86.0.322975648173.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

iso2022_tests.patch: add some tests for ISO2022 encodings:
 - testcase for iso2022_jp and iso2022_kr, iso2022_jp2 reuses iso2022_jp testcase
 - test some invalid byte sequences

----------
Added file: http://bugs.python.org/file22099/iso2022_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 01:16:11 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Tue, 24 May 2011 23:16:11 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306278971.53.0.680232620612.issue12006@psf.upfronthosting.co.za>


Changes by Ashley Anderson <aganders3 at gmail.com>:


----------
nosy: +Ashley.Anderson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 01:17:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 23:17:48 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QP0rD-0006EZ-3q@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a024183e046f by Victor Stinner in branch '3.1':
Issue #12057: Add cjkencodings directory to the Makefile and Tools/msi/msi.py
http://hg.python.org/cpython/rev/a024183e046f

New changeset 4289cc96835e by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12057: Add cjkencodings directory to the Makefile and
http://hg.python.org/cpython/rev/4289cc96835e

New changeset b2b0cae86f56 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12057: Add cjkencodings directory to the Makefile and
http://hg.python.org/cpython/rev/b2b0cae86f56

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 01:21:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 23:21:10 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QP0uT-0006Tq-Bg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8ba0192a0eb1 by Victor Stinner in branch '2.7':
Issue #12057: Add cjkencodings directory to the Makefile and Tools/msi/msi.py
http://hg.python.org/cpython/rev/8ba0192a0eb1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Wed May 25 01:22:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 23:22:32 +0000
Subject: [issue11377] Deprecate platform.popen()
In-Reply-To: <1299086966.45.0.602666513721.issue11377@psf.upfronthosting.co.za>
Message-ID: <1306279352.83.0.779677765156.issue11377@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/issue11377>
_______________________________________

From report at bugs.python.org  Wed May 25 01:30:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 23:30:38 +0000
Subject: [issue9382] os.popen referenced but not documented in Python 3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1306279838.55.0.836161796496.issue9382@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The entire os.popen*() family is supposed be gone in Python 3.x

os.popen2(), os.popen3() and os.popen4() were removed in Python 3.0, but os.popen() was kept. Guido wants to keep it because it has a nicer API than subprocess.Popen. I'm too lazy to replace all calls to os.popen() by subprocess.Popen in the Python code base: it's still widely used. Hum, I'm unable to find the issue giving more details about this choice (keep os.popen).

The os.popen() doc should be restored. Can you work on a patch?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9382>
_______________________________________

From report at bugs.python.org  Wed May 25 01:41:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2011 23:41:49 +0000
Subject: [issue10818] pydoc: Remove old server and tk panel
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <E1QP1ER-0007ou-Qx@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a30410a8fddc by Victor Stinner in branch 'default':
Issue #10818: Remove the Tk GUI of the pydoc module (pydoc -g has been
http://hg.python.org/cpython/rev/a30410a8fddc

New changeset de669b61bca4 by Victor Stinner in branch 'default':
Issue #10818: Remove deprecated pydoc.serve() function
http://hg.python.org/cpython/rev/de669b61bca4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10818>
_______________________________________

From report at bugs.python.org  Wed May 25 01:42:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 23:42:33 +0000
Subject: [issue10818] pydoc: Remove old server and tk panel
In-Reply-To: <1294071441.53.0.907267492881.issue10818@psf.upfronthosting.co.za>
Message-ID: <1306280553.49.0.168485277298.issue10818@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The old server was depreciated in 3.2 and is supposed to be removed
> along with the tk panel for 3.3.

Ok, fine. I applied your patch and removed the serve() function.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10818>
_______________________________________

From report at bugs.python.org  Wed May 25 01:43:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 23:43:47 +0000
Subject: [issue10832] Add support of bytes objects in PyBytes_FromFormatV()
In-Reply-To: <1294196110.74.0.942895284505.issue10832@psf.upfronthosting.co.za>
Message-ID: <1306280627.89.0.00217361019976.issue10832@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The "%y" format is useless for the posixmodule.c example (it doesn't simplify the code), and I cannot find another usage of this feature. So let's forget it :-)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10832>
_______________________________________

From report at bugs.python.org  Wed May 25 01:46:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2011 23:46:06 +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: <1306280766.22.0.248910197612.issue9561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I started to patch packaging to fix this issue in the packaging module: issue #12112. We might leave distutils unchanged and improve the packaging module instead (because previous experiments proved that distutils should not be touched or it break random stuffs!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Wed May 25 02:02:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 00:02:58 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <E1QP1Yu-0000hq-HI@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8be9eaf5829f by Victor Stinner in branch 'default':
Issue #8533: regrtest replaces also sys.stdout on Windows
http://hg.python.org/cpython/rev/8be9eaf5829f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Wed May 25 02:24:33 2011
From: report at bugs.python.org (Sye van der Veen)
Date: Wed, 25 May 2011 00:24:33 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1306283073.38.0.591239301202.issue10224@psf.upfronthosting.co.za>


Sye van der Veen <syeberman at rogers.com> added the comment:

I had trouble wording that sentence.  Under Unix, Makefile is used, in which you specify "PYTHON=<path>" on the command line else the default "python" (from the PATH) is used.  Under Windows, it's make.bat, where PYTHON needs to be set in the environment else "..\pcbuild\python" is used (which ignores the PATH).  In either case, there's a high likelihood the PYTHON default will resolve to 3.3a0 for any Python developer.

building.rst doesn't mention any of this, though; README.txt does.  I wanted to keep the patch small, as I suspect this issue will be properly fixed soon, but I could create a new patch that better explains how to force that 2.x be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Wed May 25 02:25:56 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 May 2011 00:25:56 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306283156.06.0.218994014815.issue12106@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here is an improved patch. Sans comments, I will apply in a few days.

----------
Added file: http://bugs.python.org/file22100/fixwith2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Wed May 25 02:38:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 00:38:30 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QP27I-0002xD-M1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 234021dcad93 by Victor Stinner in branch 'default':
Issue #8407: Fix the signal handler of the signal module: if it is called
http://hg.python.org/cpython/rev/234021dcad93

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Wed May 25 02:42:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 00:42:10 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1306284130.58.0.679849115971.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> There's a race. If a signal is received while is_tripped is set, 
> the signal number won't be written to the wakeup FD.

Oh, nice catch. The "bug" is not new, Python behaves like that since Python 3.1. But in Python < 3.3, it doesn't mater because I don't think that wakeup was used to watch more than one signal. One trigger "something happened" was enough.

The wakeup fd now contains the number of each signal, and so the behaviour has to change. I applied your patch and I added a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Wed May 25 03:17:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 May 2011 01:17:04 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306286224.1.0.0495333300256.issue12106@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just to articulate the rationale, I'm guessing the reasoning behind this is to make it feasible for source->AST->source translators to retain the original grouping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Wed May 25 03:25:12 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 May 2011 01:25:12 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306286712.12.0.639676496573.issue12106@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Visual scan of the patch in Reitveld looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Wed May 25 03:27:32 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 May 2011 01:27:32 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1306286224.1.0.0495333300256.issue12106@psf.upfronthosting.co.za>
Message-ID: <BANLkTinVtD_885fG1_Ye3ioRaKww+UG_JQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/24 Nick Coghlan <report at bugs.python.org>:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Just to articulate the rationale, I'm guessing the reasoning behind this is to make it feasible for source->AST->source translators to retain the original grouping?

Correct. It also allows my Python static analysis tool to detect when
someone could be using the double with shorthand instead of
nested-withs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Wed May 25 03:49:30 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Wed, 25 May 2011 01:49:30 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306288170.77.0.61387340117.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

I've recently joined the python-mentors mailing list because I love Python and want to get involved. I found this bug in the list of "Easy issues" and thought I'd try my hand. Anyway, this is my first patch, so please forgive me if I am breaking protocol or stepping on anyone's toes here. I also hope my code isn't embarrassing.

This adds a constructor to the date class that allows construction based on an ISO-8601 YYYYWWD string. Does this address the issue in a logical way?

----------
keywords: +patch
Added file: http://bugs.python.org/file22101/12006.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 04:26:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2011 02:26:55 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306290415.68.0.608989268944.issue12006@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for wanting to work on this.

It is a little hard to parse from the OP's initial post, but he is asking that %V and %u be supported by datetime.strptime, which they currently are not.  strptime is the generalized constructor for turning a string into a datetime, so no, a new constructor is not the right approach.

The code that implements the strptime method of datetime is in the file _strptime.py in Lib.  Your patch should be against that code.  (Note that this is pretty un-obvious, I had to dig a bit to figure it out!)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 05:21:29 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 25 May 2011 03:21:29 +0000
Subject: [issue9382] os.popen referenced but not documented in Python 3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1306293689.2.0.240030881136.issue9382@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

os.popen() is certainly deprecated. Its documentation in both 2.6 and 2.7 notes:

  Deprecated since version 2.6: This function is obsolete. Use the subprocess module.

Indeed, the Python 3.x library/os.rst doc mentions it several times, but the documentation was removed. I don't think this is following the rules of deprecation.

If it was decided to keep os.popen alive, it *should* be documented in 3.x, possibly retaining the deprecation notice.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9382>
_______________________________________

From report at bugs.python.org  Wed May 25 05:22:38 2011
From: report at bugs.python.org (Peter Hammer)
Date: Wed, 25 May 2011 03:22:38 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1306293758.78.0.861420661473.issue11889@psf.upfronthosting.co.za>


Peter Hammer <phammer at cardious.com> added the comment:

"""
Changing the 'enumerate' doc string text from:

|      (0, seq[0]), (1, seq[1]), (2, seq[2]), ...

to:

|      (start, seq[0]), (start+1, seq[1]), (start+2, seq[2]), ...

would completely disambiguate the doc string at the modest cost of
sixteen additional characters, a small price for pellucid clarity.

The proposed changes to the formal documentation also seem to me to
be prudent, and I hope at this late writing, they have already been
committed.

I conclude with a code fragment for the edification of R. David Murray.
"""


class numerate(object):
  """
  A demonstration of a plausible incorrect interpretation of
  the 'enumerate' function's doc string and documentation.
  """
  def __init__(self,seq,start=0):
    self.seq=seq; self.index=start-1
    try:
      if seq.next: pass #test for iterable
      for i in xrange(start): self.seq.next()
    except:
      if type(seq)==dict: self.seq=seq.keys()
      self.seq=iter(self.seq[start:])

  def next(self):
    self.index+=1
    return self.index,self.seq.next()
        

  def __iter__(self): return self


if __name__ == "__main__":
  #s=['spring','summer','autumn','winter']
  s={'spring':'a','summer':'b','autumn':'c','winter':'d'}
  #s=enumerate(s)#,2)
  s=numerate(s,2)
  for t in s: print t

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Wed May 25 05:56:25 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Wed, 25 May 2011 03:56:25 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306295785.47.0.284663343611.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

Thanks, I think I understand the original post now. Upon reading the docs and code, however, it seems this is possible using the %W and %w directives. Is the issue just to support the different letters (%V and %u) specifically, or that they are not quite the same format as the corresponding ISO numbers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 06:32:41 2011
From: report at bugs.python.org (Kevin)
Date: Wed, 25 May 2011 04:32:41 +0000
Subject: [issue12172] IDLE crashes when I use F5 to run
In-Reply-To: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>
Message-ID: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>


New submission from Kevin <kdness at gmail.com>:

Similar to bug issue 11431, my IDLE crashes (OS 10.6.7) when using F5, but works fine or better when I click run module. However, unlike 11431, I have downloaded, and I believe, correctly installed ActiveTcl 8.5.

Similar to Ned's suggestions in issue: 11431, here are the first two lines when I launch my shell:

Python 3.2 (r32:88452, Feb 20 2011, 11:12:31) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin

Also, here is the response when I run Ned's suggested commands per issue number 11431. First Ned's commands:

import _tkinter, subprocess
print(subprocess.getoutput("otool -L " + _tkinter.__file__))
print(subprocess.getoutput("ls -l /Library/Frameworks/Tk.framework/Versions"))

The responses:

/bin/sh: otool: command not found

total 8
drwxr-xr-x  8 root  admin  272 Feb  4 01:52 8.5
lrwxr-xr-x  1 root  admin    3 May 23 17:45 Current -> 8.5

Also, if it may help, when I click on the ActiveTCL application icon, a comodo dragon icon application named tclvfse, I get a fatal error message of which I took the following screen shot, attached.

My guess is that ActiveTcl 8.5 is partially installed, or flat out incorrectly installed.

Any ideas? Thanks for your help/time.

Kevin

----------
components: IDLE
files: Screen shot 2011-05-23 at 5.56.19 PM.png
messages: 136826
nosy: Kevin Ness
priority: normal
severity: normal
status: open
title: IDLE crashes when I use F5 to run
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file22102/Screen shot 2011-05-23 at 5.56.19 PM.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12172>
_______________________________________

From report at bugs.python.org  Wed May 25 06:46:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 May 2011 04:46:57 +0000
Subject: [issue11889] 'enumerate' 'start' parameter documentation is confusing
In-Reply-To: <1303315736.72.0.416681647484.issue11889@psf.upfronthosting.co.za>
Message-ID: <1306298817.49.0.911403965641.issue11889@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11889>
_______________________________________

From report at bugs.python.org  Wed May 25 07:54:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 25 May 2011 05:54:14 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1306302854.11.0.222896709631.issue1441530@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I've committed the patch to 2.7, and also to default (and only to default since for py3k it's more of an optimization than a bug fix).
Closing.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Wed May 25 08:25:30 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Wed, 25 May 2011 06:25:30 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306304730.53.0.651746348804.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

Getting a date from ISO week /weekday is not possible with the %W and %w directives. ISO week numbers and normal week numbers are calculated differently (see my libc qoute in the original post). Also, using %w instead of %u would be ambiguous, since %w weeks start on Sunday, while %u start with Monday.

I agree that this should be implemented in strptime(), to follow libc strptime(). datetime() has a clear constructor while strptime() has all the whacky cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 09:10:31 2011
From: report at bugs.python.org (Chris Angelico)
Date: Wed, 25 May 2011 07:10:31 +0000
Subject: [issue12173] PyImport_ImportModuleLevel doesn't have 'const' on its
	argument
In-Reply-To: <1306307431.38.0.422638235513.issue12173@psf.upfronthosting.co.za>
Message-ID: <1306307431.38.0.422638235513.issue12173@psf.upfronthosting.co.za>


New submission from Chris Angelico <rosuav at gmail.com>:

An anomaly in the argument types of similar functions: PyImport_ImportModuleLevel takes char *, while the related functions PyImport_AddModule, PyImport_ImportModule, and PyImport_ImportModuleNoBlock all take const char *. This made a nuisance of itself for me when I tried to compile my code against Python.h (embedding Python). Attached is a relatively trivial patch to add const. Should not impact existing code, as the compiler will happily pass a char* to a const char* (just not the other way).

----------
components: Interpreter Core
files: importconst.patch
keywords: patch
messages: 136829
nosy: Rosuav
priority: normal
severity: normal
status: open
title: PyImport_ImportModuleLevel doesn't have 'const' on its argument
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22103/importconst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12173>
_______________________________________

From report at bugs.python.org  Wed May 25 09:12:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 May 2011 07:12:24 +0000
Subject: [issue12173] PyImport_ImportModuleLevel doesn't have 'const' on its
	argument
In-Reply-To: <1306307431.38.0.422638235513.issue12173@psf.upfronthosting.co.za>
Message-ID: <1306307544.77.0.45685451822.issue12173@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +needs review
nosy: +brett.cannon, haypo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12173>
_______________________________________

From report at bugs.python.org  Wed May 25 09:25:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 25 May 2011 07:25:35 +0000
Subject: [issue12172] IDLE crashes when I use F5 to run
In-Reply-To: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>
Message-ID: <1306308335.63.0.372582671885.issue12172@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

How are you launching IDLE? Are you sure you aren't launching the IDLE for the Apple-supplied Python 2.6?  The two easiest ways to launch IDLE 3.2 are to either double-click on the IDLE file in the /Applications/Python 3.2 folder or, from a terminal shell window, type /usr/local/bin/idle3.2.  The resulting "Python Shell" window should say Python 3.2.  If you still get a crash, please report any relevant output from the system.log; you can use /Applications/Utilities/Console.app to examine system.log.  Or, if there is an OS X crash report, report the output from that.  You could also verify the patch level of the ActiveState Tcl by doing the following:

    cd /Library/Frameworks/Tcl.framework
    grep TCL_VERSION tclConfig.sh
    # should be "TCL_VERSION='8.5'"
    grep TCL_PATCH tclConfig.sh
    # should be "TCL_PATCH_LEVEL='.9'"

----------
assignee:  -> ned.deily
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12172>
_______________________________________

From report at bugs.python.org  Wed May 25 10:23:15 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 May 2011 08:23:15 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <1306273701.0.0.285113776535.issue12171@psf.upfronthosting.co.za>
Message-ID: <4DDCBC6E.5000703@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Do we need an additional method? It seems that this reset() could also be written encoder.encode('', final=True)

+1

I think that's a much more natural way to implement "finalize the
encoding output without adding any data to it".

----------
title: Reset method of the incremental encoders of CJK codecs calls the decoder reset function -> Reset method of the incremental encoders of CJK codecs	calls the decoder reset function

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Wed May 25 11:15:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 09:15:22 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <E1QPABU-0005Nm-MI@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 96a82c973224 by Victor Stinner in branch 'default':
Issue #12049: test_ssl now checks also that RAND_bytes() raises an error if
http://hg.python.org/cpython/rev/96a82c973224

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Wed May 25 11:27:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 09:27:44 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <E1QPANT-0006Ip-2h@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 178d367c9733 by Victor Stinner in branch 'default':
Issue #12049: Document errors cases of ssl.RAND_bytes() and
http://hg.python.org/cpython/rev/178d367c9733

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Wed May 25 11:47:10 2011
From: report at bugs.python.org (Lukas Petru)
Date: Wed, 25 May 2011 09:47:10 +0000
Subject: [issue12165] Does nonlocal include global?
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1306316830.57.0.989977127633.issue12165@psf.upfronthosting.co.za>


Lukas Petru <lukas.petru at seznam.cz> added the comment:

Well, I read that text before, but it may be because I am not native english speaker that I interpret the text differently. Let's go through it one step at a time and show me where I am wrong.

1) The nonlocal statement causes the listed identifiers to refer to previously bound variables in the nearest enclosing scope.

- I assume here that global scope is an enclosing scope (global encloses everything in the module).

2) The statement allows encapsulated code to rebind variables outside of the local scope besides the global (module) scope.

- Here I interpret "besides" as "in addition to".

Nothing specifically says that global bindings are excluded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Wed May 25 12:02:03 2011
From: report at bugs.python.org (Giuseppe Laurenza)
Date: Wed, 25 May 2011 10:02:03 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1306317723.43.0.538224363393.issue11272@psf.upfronthosting.co.za>


Giuseppe Laurenza <giuseppe.laurenza at gmail.com> added the comment:

On my pc with both architecture (x86 and x64) the bug is still presentes

----------
nosy: +Phoenix Fire

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed May 25 12:16:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 10:16:09 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1306318569.67.0.0643606613772.issue11272@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> On my pc with both architecture (x86 and x64) the bug
> is still presentes

Which version of Python are you using? Python 3.1, Python 3.2.1 and Python 3.3 doesn't have the bug, Python 3.2.0 has the bug. Python 3.2.1 doesn't have the bug, but it's not released yet: it will be released in a few weeks. Python 3.3 is a development version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed May 25 12:32:16 2011
From: report at bugs.python.org (Giuseppe Laurenza)
Date: Wed, 25 May 2011 10:32:16 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1306318569.67.0.0643606613772.issue11272@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=EfbhPYvhV86HjnmTo83g_x6fLmw@mail.gmail.com>


Giuseppe Laurenza <giuseppe.laurenza at gmail.com> added the comment:

I'm using the 3.2,
the 3.0 has the bug?

2011/5/25 STINNER Victor <report at bugs.python.org>

>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> > On my pc with both architecture (x86 and x64) the bug
> > is still presentes
>
> Which version of Python are you using? Python 3.1, Python 3.2.1 and Python
> 3.3 doesn't have the bug, Python 3.2.0 has the bug. Python 3.2.1 doesn't
> have the bug, but it's not released yet: it will be released in a few weeks.
> Python 3.3 is a development version.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11272>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22104/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________
-------------- next part --------------
I&#39;m using the 3.2,<div>the 3.0 has the bug?<br><br><div class="gmail_quote">2011/5/25 STINNER Victor <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>
STINNER Victor &lt;<a href="mailto:victor.stinner at haypocalc.com">victor.stinner at haypocalc.com</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; On my pc with both architecture (x86 and x64) the bug<br>
&gt; is still presentes<br>
<br>
</div>Which version of Python are you using? Python 3.1, Python 3.2.1 and Python 3.3 doesn&#39;t have the bug, Python 3.2.0 has the bug. Python 3.2.1 doesn&#39;t have the bug, but it&#39;s not released yet: it will be released in a few weeks. Python 3.3 is a development version.<br>

<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue11272" target="_blank">http://bugs.python.org/issue11272</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Wed May 25 13:14:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 11:14:06 +0000
Subject: [issue12049] expose RAND_bytes() function of OpenSSL
In-Reply-To: <1305015011.4.0.908313751711.issue12049@psf.upfronthosting.co.za>
Message-ID: <E1QPC2P-0006ZP-03@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 195de3d10879 by Victor Stinner in branch 'default':
Issue #12049: cleanup the warning in the random module doc
http://hg.python.org/cpython/rev/195de3d10879

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12049>
_______________________________________

From report at bugs.python.org  Wed May 25 13:54:07 2011
From: report at bugs.python.org (JJeffries)
Date: Wed, 25 May 2011 11:54:07 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>


New submission from JJeffries <jamesjeffries1 at gmail.com>:

It is unclear without reference to the logging module where the multiprocessing logging levels fit in the normal logging provided by the logging module, even though it says above the table

"The table below illustrates where theses fit in the
normal level hierarchy.

+----------------+----------------+
| Level          | Numeric value  |
+================+================+
| ``SUBWARNING`` | 25             |
+----------------+----------------+
| ``SUBDEBUG``   | 5              |
+----------------+----------------+"

I propose adding further values from the logging module for clarification.

----------
assignee: docs at python
components: Documentation
messages: 136839
nosy: JJeffries, docs at python
priority: normal
severity: normal
status: open
title: Multiprocessing logging levels unclear
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Wed May 25 14:14:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 12:14:00 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

FileIO.readall() reads the file position and size before each call to read(), to adjust the buffer size.

Moreover FileIO.readall() calls lseek() on Windows: it should use _lseeki64() instead, to handle correctly file bigger than 2 GB (or maybe 4 GB? I don't know).

Attached patch fixes both problems.

--

BufferedReader.read() calls FileIO.read() until FileIO.read() returns an empty byte string. Why not calling FileIO.read() only once?

----------
components: IO
files: fileio_readall.patch
keywords: patch
messages: 136840
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: FileIO.readall() read the file position and size at each read
versions: Python 3.3
Added file: http://bugs.python.org/file22105/fileio_readall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 14:19:23 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 25 May 2011 12:19:23 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1306325963.98.0.18262489514.issue12174@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

It seems that the documentation of logging no longer gives a table with numeric values for levels (I remember seeing it before). Maybe it would be most useful to remove the table from multiprocessing documentation and state it explicitly that "SUBDEBUG is lower than DEBUG and SUBWARNING is between INFO and WARNING".

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Wed May 25 14:19:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 12:19:47 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306325983.3580.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> BufferedReader.read() calls FileIO.read() until FileIO.read() returns
> an empty byte string. Why not calling FileIO.read() only once?

BufferedReader doesn't call FileIO.read, it calls <rawio>.read().
The latter can be e.g. a socket and call recv(). If you want to read
till the end of stream, you have to repeat until recv() returns the
empty string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 14:21:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 12:21:27 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306326085.3580.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> FileIO.readall() reads the file position and size before each call to
> read(), to adjust the buffer size.
> 
> Moreover FileIO.readall() calls lseek() on Windows: it should use
> _lseeki64() instead, to handle correctly file bigger than 2 GB (or
> maybe 4 GB? I don't know).
> 
> Attached patch fixes both problems.

Looks ok to me. Did you test under Windows? Did you run some benchmarks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 14:32:06 2011
From: report at bugs.python.org (JJeffries)
Date: Wed, 25 May 2011 12:32:06 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1306326726.47.0.397876371007.issue12174@psf.upfronthosting.co.za>


Changes by JJeffries <jamesjeffries1 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22106/multiprocessing_logging.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Wed May 25 14:39:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 25 May 2011 12:39:37 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1306327177.92.0.869995340681.issue12174@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The patch is in an invalid format. See http://docs.python.org/devguide/patch.html for instructions on working with patches. If you cannot/won't use Mercurial, use two separate directories for original and modified cpython source tree, and invoke:

    diff -urN cpython-orig cpython-modified

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Wed May 25 16:09:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 14:09:26 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306332566.11.0.0910708578858.issue12175@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, FileIO.readall() doesn't raise a ValueError if the file is closed => patch attached to fix this.

----------
Added file: http://bugs.python.org/file22107/fileio_readall_closed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 16:10:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 14:10:57 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306332657.66.0.111012266877.issue12175@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+            raw = f
+            if hasattr(raw, 'buffer'):
+                raw = raw.buffer
+            if hasattr(raw, 'raw'):
+                raw = raw.raw
             f.close()
             self.assertRaises(ValueError, f.flush)
             self.assertRaises(ValueError, f.fileno)
@@ -2512,6 +2517,7 @@ class MiscIOTest(unittest.TestCase):
             self.assertRaises(ValueError, f.read)
             if hasattr(f, "read1"):
                 self.assertRaises(ValueError, f.read1, 1024)
+            self.assertRaises(ValueError, raw.readall)

Why not simply:

             if hasattr(f, "readall"):
                 self.assertRaises(ValueError, f.readall, 1024)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 16:12:04 2011
From: report at bugs.python.org (Carl Crowder)
Date: Wed, 25 May 2011 14:12:04 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306332724.0.0.600805083672.issue12168@psf.upfronthosting.co.za>


Carl Crowder <carl.crowder at gmail.com> added the comment:

Flume certainly could avoid parsing certain values. However, while a syslog application "should avoid octet values below 32", they are still "legal" [1]. I don't think that adjusting flume to reject legal values due to legacy behaviour in some unix syslog daemons is the Right Thing? here.

[1] http://tools.ietf.org/html/rfc5424#section-6.4

----------
title: SysLogHandler incorrectly appents \000 to messages -> SysLogHandler incorrectly appends \000 to messages

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Wed May 25 16:28:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 14:28:11 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306333691.02.0.529350249929.issue12175@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

RawIOBase.readall() fails if .read() returns None: fix attached.

----------
Added file: http://bugs.python.org/file22108/rawiobase_readall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 16:28:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 14:28:49 +0000
Subject: [issue12173] PyImport_ImportModuleLevel doesn't have 'const' on its
	argument
In-Reply-To: <1306307431.38.0.422638235513.issue12173@psf.upfronthosting.co.za>
Message-ID: <E1QPF4q-00088J-GB@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a9126e8770e5 by Benjamin Peterson in branch 'default':
make PyImport_ImportModuleLevel's first arg const like similiar functions (closes #12173)
http://hg.python.org/cpython/rev/a9126e8770e5

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12173>
_______________________________________

From report at bugs.python.org  Wed May 25 16:54:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 14:54:19 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306335259.45.0.637805675539.issue12175@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

bufferedreader_readall.patch: BufferedReader.read(None) calls raw.readall() if available.

bufferedreader_readall.patch requires fileio_readall_closed.patch and rawiobase_readall.patch fixes.

----------
Added file: http://bugs.python.org/file22109/bufferedreader_readall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 17:00:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 15:00:37 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306335259.45.0.637805675539.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306335635.3580.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> bufferedreader_readall.patch: BufferedReader.read(None) calls
> raw.readall() if available.

Have you run any benchmarks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 17:04:39 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 25 May 2011 15:04:39 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1306335879.42.0.362300340052.issue12174@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Converted the patch by JJeffries to a valid format.

----------
Added file: http://bugs.python.org/file22110/multiprocessing_logging_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Wed May 25 17:05:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 15:05:55 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306335955.56.0.510297966067.issue12175@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Number of syscalls without the patch -> with the patch:

- read the README file, text mode: 17 -> 12 syscalls (-5)
- read the README file, binary mode: 15 -> 11 syscalls (-4)
- read a binary file of 10 MB: 17 -> 12 syscalls (-5)

Quick benchmark open('README').read(); open('README', 'rb').read() in a loop: 359.1 ms -> 335.4 ms (-7%). So it's not really faster.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 17:16:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2011 15:16:36 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1306336596.49.0.272955182701.issue11272@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are using the only version that has the bug (3.2.0, also called 3.2).  The fixed version will be released shortly (3.2.1).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed May 25 17:20:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 15:20:51 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306336851.45.0.175710284572.issue12175@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

About rawiobase_readall.patch: why do you use PyObject_Size() if you know chunks is a list? PyList_GET_SIZE is much more efficient.

About bufferedreader_readall.patch:

+            PyBytes_Concat(&data, all);
+            if (data == NULL)
+                return NULL;

You must Py_DECREF(all) first.

Also, you should check that "all" is either None or a bytes object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 17:28:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2011 15:28:40 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306337320.01.0.00987155458181.issue12168@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

And it goes on to say:

"[...] but a syslog application MAY modify these characters upon reception.  For example, it might change them into an escape sequence (e.g., value 0 may be changed to "\0")"

Flume should not break if it receives NULs.  But there should be a way to prevent generating them, and Vinay has agreed with that.  Now we just need a patch :)  (he's probably working on one...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Wed May 25 17:31:22 2011
From: report at bugs.python.org (Carl Crowder)
Date: Wed, 25 May 2011 15:31:22 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306337482.42.0.407167489108.issue12168@psf.upfronthosting.co.za>


Carl Crowder <carl.crowder at gmail.com> added the comment:

Oh, I understand. Flume doesn't break, it handles the \0 just fine, the problem is that I ended up with a message with that additional byte on the end. Sorry for the confusion!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Wed May 25 17:35:47 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 25 May 2011 15:35:47 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306337747.88.0.110347662018.issue12168@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

FWIW, I once stumbled on this problem, and solved it by making my own log handler that uses functions from the syslog module.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Wed May 25 18:02:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 25 May 2011 16:02:11 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306337747.88.0.110347662018.issue12168@psf.upfronthosting.co.za>
Message-ID: <316848.62625.qm@web25806.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Petri Lehtinen <petri at digip.org> added the  comment:

> 
> FWIW, I once stumbled on this problem, and solved it by making  my own log 
>handler that uses functions from the syslog  module.

@Petri: It's great that it worked for you, but IIRC the syslog module has had 
thread-safety issues at least on some platforms, which is why it's not used in 
the SysLogHandler implementation (disclaimer: this was a while ago, I don't know 
if the syslog module is thread-safe now - I believe the thread-safety issues 
were in the underlying C APIs).

I am working on a patch, watch this space :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Wed May 25 18:06:57 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 25 May 2011 16:06:57 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <316848.62625.qm@web25806.mail.ukl.yahoo.com>
Message-ID: <20110525160655.GI10448@colossus>


Petri Lehtinen <petri at digip.org> added the comment:

Vinay Sajip wrote:
> @Petri: It's great that it worked for you, but IIRC the syslog module has had 
> thread-safety issues at least on some platforms, which is why it's not used in 
> the SysLogHandler implementation (disclaimer: this was a while ago, I don't know 
> if the syslog module is thread-safe now - I believe the thread-safety issues 
> were in the underlying C APIs).

Ah, I was not aware of thread safety issues. A quick search revealed
that there has been a non-standard syslog_r() function that's thread
safe, but nowadays POSIX requires syslog() to be thread safe, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Wed May 25 18:17:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 16:17:32 +0000
Subject: [issue12045] external shell command executed twice in
	ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <E1QPGm2-0001mm-Ip@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c540b18b00b9 by Antoine Pitrou in branch 'default':
Issue #12045: Avoid duplicate execution of command in ctypes.util._get_soname().
http://hg.python.org/cpython/rev/c540b18b00b9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Wed May 25 18:17:58 2011
From: report at bugs.python.org (Pavel Bogdanovic)
Date: Wed, 25 May 2011 16:17:58 +0000
Subject: [issue12176] Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
In-Reply-To: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>
Message-ID: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>


New submission from Pavel Bogdanovic <pabo3000 at googlemail.com>:

Compiling of Python does end with an error.

It has to do with changes in Ubuntu: https://wiki.ubuntu.com/MultiarchSpec

I added one line after python's setup.py after line 351
 add_dir_to_list(self.compiler.library_dirs, '/usr/lib/i386-linux-gnu')

and it compiled.
It might be archeticture-dependent. Perhaps it should account
(/lib/i386-linux-gnu
   /lib/x86_64-linux-gnu
   /usr/lib/i386-linux-gnu
   /usr/lib/x86_64-linux-gnu)

----------
components: Build
files: patch_setup.py
messages: 136862
nosy: Pavel.Bogdanovic
priority: normal
severity: normal
status: open
title: Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file22111/patch_setup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12176>
_______________________________________

From report at bugs.python.org  Wed May 25 18:23:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 16:23:49 +0000
Subject: [issue12098] Child process running as debug on Windows
In-Reply-To: <1305664733.32.0.991268423513.issue12098@psf.upfronthosting.co.za>
Message-ID: <1306340629.21.0.000169775629976.issue12098@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, thanks for the patches. Some further comments:
- the function generating the flags should be exported (with a private name), so that it can be reused by Lib/test/[test_]support.py. Duplicate code is error-prone, especially when enumerating command-line flags, attribute names...
- in the tests, proc_flags() could simply return tuple(sys.flags). This is simpler and easier to maintain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12098>
_______________________________________

From report at bugs.python.org  Wed May 25 18:24:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 16:24:20 +0000
Subject: [issue12045] external shell command executed twice in
	ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <1306340660.21.0.411340173929.issue12045@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed, thank you!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Wed May 25 18:24:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 25 May 2011 16:24:21 +0000
Subject: [issue12176] Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
In-Reply-To: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>
Message-ID: <1306340661.98.0.365493233696.issue12176@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Are you on a 64-bit Ubuntu? Could you attach or copy/paste the error message?

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12176>
_______________________________________

From report at bugs.python.org  Wed May 25 18:26:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 16:26:47 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <E1QPGv0-0002d6-4x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e2363b1c4bca by Senthil Kumaran in branch 'default':
Fix closes issue #11109 -  socketserver.ForkingMixIn leaves zombies, also fails to reap all zombies in one pass.
http://hg.python.org/cpython/rev/e2363b1c4bca

New changeset 3e3cd0ed82bb by Senthil Kumaran in branch 'default':
News entry for issue11109.
http://hg.python.org/cpython/rev/3e3cd0ed82bb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Wed May 25 18:31:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 25 May 2011 16:31:08 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1306341068.63.0.505624834067.issue11109@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The feature is in 3.3. I did not remove the handle_timeout method from the Mixin class, because it might be used in the production by the existing servers. It is not appropriate to remove methods all of sudden without deprecation warnings and also it is not required to remove in this case.

Added the Documentation and News entry too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Wed May 25 18:33:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 25 May 2011 16:33:09 +0000
Subject: [issue12170] Bytes objects do not accept integers to many functions
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306341189.08.0.114815197475.issue12170@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/issue12170>
_______________________________________

From report at bugs.python.org  Wed May 25 18:42:56 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 May 2011 16:42:56 +0000
Subject: [issue12176] Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
In-Reply-To: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>
Message-ID: <1306341776.91.0.246055166264.issue12176@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This should have been fixed in issue 11715. Could you try to
build from a mercurial checkout?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12176>
_______________________________________

From report at bugs.python.org  Wed May 25 18:44:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 25 May 2011 16:44:50 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1306341890.09.0.0299668647712.issue11109@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is fixed in 3.3 now. Keeping it open for test_socketserver update. After a ForkingServer service call, it should be asserted the collect_children routine is run.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Wed May 25 18:46:36 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 25 May 2011 16:46:36 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305989427.99.0.785757675893.issue12107@psf.upfronthosting.co.za>
Message-ID: <BANLkTik6mSSDYU3AaFc6h3s2=BkiHicoMA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

So, SOCK_CLOEXEC is available.
Note that I don't like the idea of falling back to FD_CLOEXEC since
it's not atomic, and some people might rely on this.
Can we close this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Wed May 25 18:51:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 25 May 2011 16:51:01 +0000
Subject: [issue12071] test_concurrent_futures.test_context_manager_shutdown()
	hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1306342261.57.0.75291218892.issue12071@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Since it's a OOM issue, can we close?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12071>
_______________________________________

From report at bugs.python.org  Wed May 25 18:53:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 16:53:15 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1306342395.92.0.512874319785.issue12107@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So, SOCK_CLOEXEC is available.
> Note that I don't like the idea of falling back to FD_CLOEXEC since
> it's not atomic, and some people might rely on this.
> Can we close this issue?

Well, this is apparently a feature request for socketserver.TCPServer.
I don't see any problem in adding a best-effort option to add the cloexec flag, possibly atomically, and fall back on FD_CLOEXEC.

People who "rely on this" can only do it if their system supports it anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Wed May 25 19:06:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 17:06:14 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1306343174.37.0.499325207995.issue12107@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, the best effort approach is already used in subprocess (check subprocess_cloexec_pipe() in Modules/_posixsubprocess.c).

Speaking of which, the os module could expose the pipe2() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Wed May 25 19:10:02 2011
From: report at bugs.python.org (Pavel Bogdanovic)
Date: Wed, 25 May 2011 17:10:02 +0000
Subject: [issue12176] Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
In-Reply-To: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>
Message-ID: <1306343402.01.0.410614763956.issue12176@psf.upfronthosting.co.za>


Pavel Bogdanovic <pabo3000 at googlemail.com> added the comment:

yes, the patch mentioned in issue 11715 works.
Sorry for crossposting the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12176>
_______________________________________

From report at bugs.python.org  Wed May 25 19:16:35 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 25 May 2011 17:16:35 +0000
Subject: [issue12168] SysLogHandler incorrectly appends \000 to messages
In-Reply-To: <1306237453.36.0.871696790191.issue12168@psf.upfronthosting.co.za>
Message-ID: <1306343795.41.0.484831052513.issue12168@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Please note: this change is too late for inclusion in Python 3.2.1 :-( as it has already rc status. So I will probably push this change once 3.2.1 is out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12168>
_______________________________________

From report at bugs.python.org  Wed May 25 19:19:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 May 2011 17:19:46 +0000
Subject: [issue12176] Compiling Python 2.7.1 on Ubuntu 11.04 (Natty Narwhale)
In-Reply-To: <1306340278.4.0.0909573730706.issue12176@psf.upfronthosting.co.za>
Message-ID: <1306343986.59.0.638867059698.issue12176@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks for testing. I guess we can close this one then.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12176>
_______________________________________

From report at bugs.python.org  Wed May 25 19:39:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 May 2011 17:39:08 +0000
Subject: [issue12165] Does nonlocal include global?
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1306345148.87.0.344024045503.issue12165@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Lukas, I'll fix-up the docs.  Thanks for pointing out the deficiency.

----------
assignee:  -> rhettinger
components: +Documentation -Interpreter Core
nosy: +rhettinger
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Wed May 25 19:41:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2011 17:41:16 +0000
Subject: [issue12170] Bytes.index() and bytes.count() do not accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306345276.32.0.812617899215.issue12170@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> It is certainly unusual for n to be in the sequence, but not to be able to find it.

Agreed. Doc Lib: 4.6. Sequence Types ? str, bytes, bytearray, list, tuple, range says '''
s.index(i) index of the first occurence of i in s   
s.count(i) total number of occurences of i in s '''
so everything *in* a bytes should be valid for .index and .count.

>>> test = b'0120'
>>> z = b'0'
>>> zo = ord(z)
>>> z in test
True
>>> zo in test
True
>>> test.index(z)
0
>>> test.index(zo)
...
TypeError: expected an object with the buffer interface
>>> test.count(z)
2
>>> test.count(zo)
...
TypeError: expected an object with the buffer interface
# longer subsequences like b'01' also work

So I think the code for 3.2+ bytes.count() and bytes.index() should do the same branching as the code for bytes.__contains__.

The other functions you list, including .rindex are not general sequence functions but are string functions defined as taking subsequences as inputs. So they would never be used in generic code like .count and .index can be.

----------
nosy: +terry.reedy
stage:  -> test needed
title: Bytes objects do not accept integers to many functions -> Bytes.index() and bytes.count() do not accept byte ints
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed May 25 19:41:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2011 17:41:53 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306345313.47.0.304525547993.issue12170@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Bytes.index() and bytes.count() do not accept byte ints -> Bytes.index() and bytes.count() should accept byte ints

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed May 25 19:42:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 May 2011 17:42:31 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306345351.95.0.160236990425.issue12170@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/issue12170>
_______________________________________

From report at bugs.python.org  Wed May 25 19:59:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 25 May 2011 17:59:31 +0000
Subject: [issue12107] TCP listening sockets created without FD_CLOEXEC flag
In-Reply-To: <1305799797.97.0.620178098753.issue12107@psf.upfronthosting.co.za>
Message-ID: <1306346371.26.0.304075036958.issue12107@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Well, this is apparently a feature request for socketserver.TCPServer.

Honestly, I'm not sure what this request is about.
The original request seemed to imply this should be made the default. I don't agree, and think this should be made optional. Also, the title is much more general: "TCP listening sockets created without FD_CLOEXEC flag".

> I don't see any problem in adding a best-effort option to add the cloexec flag, possibly atomically, and fall back on FD_CLOEXEC.
> People who "rely on this" can only do it if their system supports it anyway.

I wasn't clear. I thought we were talking about the socket constructor. In that case, yes, we could do that for socketserver, but with an explicit warning (because with a cloexec flag to a constructor, people will unconsciously expect it to behave like SOCK_CLOEXEC and be atomic).

> Speaking of which, the os module could expose the pipe2() function.

I'll work on a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________

From report at bugs.python.org  Wed May 25 20:04:25 2011
From: report at bugs.python.org (EungJun Yi)
Date: Wed, 25 May 2011 18:04:25 +0000
Subject: [issue12177] re.match raises MemoryError
In-Reply-To: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>
Message-ID: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>


New submission from EungJun Yi <semtlenori at gmail.com>:

re.match raises MemoryError when trying to match r'()+?1' to 'a1', as shown below.

~$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match(r'()+?1', 'a1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/re.py", line 137, in match
    return _compile(pattern, flags).match(string)
MemoryError
>>>

~$ python3
Python 3.2 (r32:88445, Mar 25 2011, 19:28:28) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match(r'()+?1', 'a1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/re.py", line 153, in match
    return _compile(pattern, flags).match(string)
MemoryError
>>>

----------
components: Regular Expressions
messages: 136880
nosy: EungJun.Yi
priority: normal
severity: normal
status: open
title: re.match raises MemoryError
type: resource usage
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12177>
_______________________________________

From report at bugs.python.org  Wed May 25 20:27:11 2011
From: report at bugs.python.org (Eric Breck)
Date: Wed, 25 May 2011 18:27:11 +0000
Subject: [issue12178] csv writer doesn't escape escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>


New submission from Eric Breck <ebreck at gmail.com>:

Consider the attached two files.  A reader and writer with the same dialect parameters (escapechar \ quotechar " doublequote False) read, then write a CSV cell that looks like "C\\".  It's written "C\".  The problem is, when doublequote=False, the escapechar isn't used to escape itself, and the writer writes something that in the same dialect would be understood differently (\" isn't \ then end of string, it's an escaped quotechar within the string).

Execute python err.py first.csv to see.

----------
components: None
files: pybug.zip
messages: 136881
nosy: ebreck
priority: normal
severity: normal
status: open
title: csv writer doesn't escape escapechar
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file22112/pybug.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12178>
_______________________________________

From report at bugs.python.org  Wed May 25 20:32:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2011 18:32:01 +0000
Subject: [issue12165] Does nonlocal include global?
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1306348321.32.0.436383209393.issue12165@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Another problem with the current text is that it fails to exclude enclosing class scopes, and I had to test to be sure they were., and some of the phrasing strikes me as awkward. Here is a possible rewrite.

"When the definition of a function is nested (enclosed) within the definitions of other functions, its nonlocal scopes are the local scopes of the enclosing functions. The nonlocal statement causes the listed identifiers to refer to names previously bound in nonlocal scopes. If a name is bound in more than one nonlocal scope, the nearest binding is used. If a name is not bound in any nonlocal scope, or if there is no nonlocal scope, a SyntaxError is raised.

Except for the requirement that the listed indentifiers be previously bound, the nonlocal statement is similar to the global statement. It applies to the entire function body, so it cannot follow any local bindings of the same names."

My main change is to first unambiguously define nonlocal scopes and continue from there.

----------
keywords: +patch
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Wed May 25 20:32:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2011 18:32:53 +0000
Subject: [issue12165] Nonlocal does not include global; clarify doc
In-Reply-To: <1306216657.18.0.255448168009.issue12165@psf.upfronthosting.co.za>
Message-ID: <1306348373.64.0.176954599794.issue12165@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Does nonlocal include global? -> Nonlocal does not include global; clarify doc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12165>
_______________________________________

From report at bugs.python.org  Wed May 25 20:34:54 2011
From: report at bugs.python.org (Max)
Date: Wed, 25 May 2011 18:34:54 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306348494.07.0.124131903365.issue12170@psf.upfronthosting.co.za>


Max <max at alleged.net> added the comment:

Fair enough.

I think it would make sense for the string methods to also accept single ints where possible as well:

For haystack and needles both strings:
[haystack.find(n) for n in needles]

For both bytes, it's a bit contortionist:
[haystack.find(needles[i:i+1]) for i in range(len(needles))]

One ends up doing a lot of the [i:i+1] bending when using bytes functions.

----------
type: behavior -> 
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed May 25 20:36:49 2011
From: report at bugs.python.org (Max)
Date: Wed, 25 May 2011 18:36:49 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306348609.13.0.553187272696.issue12170@psf.upfronthosting.co.za>


Changes by Max <max at alleged.net>:


----------
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12170>
_______________________________________

From report at bugs.python.org  Wed May 25 20:43:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2011 18:43:00 +0000
Subject: [issue12172] IDLE crashes when I use F5 to run
In-Reply-To: <1306297960.86.0.861957581739.issue12172@psf.upfronthosting.co.za>
Message-ID: <1306348980.73.0.162013520455.issue12172@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Did I read right?
Clicking F5 crashes while clicking Run and then 'Run Module F5' works?
(They ought to be the same thing.)
If so, check the key bindings. Options/Configure IDLE .../Keys.
There should be an entry 'Run Module - <Key-F5>'.
Is F5 bound to anything else?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12172>
_______________________________________

From report at bugs.python.org  Wed May 25 20:49:53 2011
From: report at bugs.python.org (wrobell)
Date: Wed, 25 May 2011 18:49:53 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306349393.69.0.20881456615.issue3754@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

Would it be possible to get list of steps required to test this patch?

1. hg clone
2. copy config.sub and config.guess?
3. autoreconf
4. configure...
5. make

What else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed May 25 21:30:16 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Wed, 25 May 2011 19:30:16 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306351816.88.0.896189114157.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

OK, here is my second attempt. I think it functions as desired, but a code review may reveal flaws in my implementation. I'm sure there are associated tests and documentation to write, but I have basically no experience with that yet. If this looks like the right direction, I can take it to the python-mentors list for help with the test/docs.

----------
Added file: http://bugs.python.org/file22113/12006_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 21:30:25 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Wed, 25 May 2011 19:30:25 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306351825.33.0.177417218211.issue12006@psf.upfronthosting.co.za>


Changes by Ashley Anderson <aganders3 at gmail.com>:


Removed file: http://bugs.python.org/file22101/12006.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 21:42:24 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 25 May 2011 19:42:24 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1306349393.69.0.20881456615.issue3754@psf.upfronthosting.co.za>
Message-ID: <4DDD5B9C.2050901@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Usually this is not a question for bug-tracking system . configure .. 
--host=.... will enter into cross-compilation mode. You could find more 
details into respective manual.

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed May 25 21:58:14 2011
From: report at bugs.python.org (Sye van der Veen)
Date: Wed, 25 May 2011 19:58:14 +0000
Subject: [issue12179] Race condition using PyGILState_Ensure on a new thread
In-Reply-To: <1306353494.72.0.953237135168.issue12179@psf.upfronthosting.co.za>
Message-ID: <1306353494.72.0.953237135168.issue12179@psf.upfronthosting.co.za>


New submission from Sye van der Veen <syeberman at rogers.com>:

I'm wanting to call PyThreadState_SetAsyncExc from a function registered with SetConsoleCtrlHandler.  To do so, I need to call PyGILState_Ensure, which asserts that Python is initialized, so I need to check for that.  However, I noticed a race condition with the code:

  if( Py_IsInitialized( ) ) {
    // XXX What if another thread calls Py_Finalize here?
    gstate = PyGILState_Ensure( );
    PyThreadState_SetAsyncExc( MainThreadId, PyExc_SystemExit );
    PyGILState_Release( gstate );
  }

What I need is to be able to hold the GIL around the entire block of code, potentially before Py_Initialize is called for the first time.  Now, 3.2 deprecated PyEval_AcquireLock, and PyEval_InitThreads can no longer be called before Py_Initialize.  Thankfully, I'm on 2.6.4, so I was able to write this code:

  PyEval_AcquireLock( );
  if( Py_IsInitialized( ) ) {
    gstate = PyGILState_Ensure( );
    PyThreadState_SetAsyncExc( MainThreadId, PyExc_SystemExit );
    PyGILState_Release( gstate );
  }
  PyEval_ReleaseLock( );

The problem in 2.6.4 is that PyGILState_Ensure deadlocks because the GIL is already held, so that doesn't solve my problem.  (Incidentally, the PyGILState_Ensure docs say it works "regardless of the current state of the GIL", which is incorrect.)

The 3.2 docs say to use PyEval_AcquireThread or PyEval_RestoreThread, which both require an existing PyThreadState.  To get that, I would need to call PyThreadState_New, which needs a PyInterpreterState.  To get _that_ I could use PyInterpreterState_Head, since I know I only use one interpreter.  Now I'm getting into "advanced debugger" territory, but it's no use anyway; it's possible that Py_Finalize could sneak in between the time I get this interpreter and when I acquire the GIL, causing me to access a free'd interpreter.

I believe the best fix for this would be to have a version of PyGILState_Ensure that works even when Python is not initialized.  It would not be able to create a thread, and thus I would not expect to be able to call any Python API, but it would always ensure the GIL is acquired.  This _may_ have to be a new "PyGILState_EnsureEx" function, because existing code expects PyGILState_Ensure to always allow them to call the Python API.  The resulting code would be:

  gstate = PyGILState_EnsureEx( );
  if( Py_IsInitialized( ) ) {
    PyThreadState_SetAsyncExc( MainThreadId, PyExc_SystemExit );
  }
  PyGILState_Release( gstate );

This would require that Py_Initialize itself acquires the GIL.

The above problem was found on 2.6.4, but I've consulted the 3.2 docs and 3.3 code (via the online source) and it looks like the situation would be exactly the same.  In the meantime, I'm going to stick with the first piece of code and hope nobody hits CTRL-BREAK during program clean-up.

----------
components: Interpreter Core
messages: 136888
nosy: syeberman
priority: normal
severity: normal
status: open
title: Race condition using PyGILState_Ensure on a new thread
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/issue12179>
_______________________________________

From report at bugs.python.org  Wed May 25 22:02:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 20:02:45 +0000
Subject: [issue12179] Race condition using PyGILState_Ensure on a new thread
In-Reply-To: <1306353494.72.0.953237135168.issue12179@psf.upfronthosting.co.za>
Message-ID: <1306353765.61.0.0511325360582.issue12179@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +charles-francois.natali, haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12179>
_______________________________________

From report at bugs.python.org  Wed May 25 22:06:58 2011
From: report at bugs.python.org (Nir Aides)
Date: Wed, 25 May 2011 20:06:58 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306354018.55.0.115849439237.issue1625@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Right! I updated the patch and added a test for the aligned stream/buffer case.

----------
Added file: http://bugs.python.org/file22114/cpython-bz2-streams.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Wed May 25 22:07:54 2011
From: report at bugs.python.org (Nir Aides)
Date: Wed, 25 May 2011 20:07:54 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306354074.76.0.356817853773.issue1625@psf.upfronthosting.co.za>


Changes by Nir Aides <nir at winpdb.org>:


Removed file: http://bugs.python.org/file22087/cpython-bz2-streams.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Wed May 25 22:09:31 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 May 2011 20:09:31 +0000
Subject: [issue12180] test_packaging: failures --without-threads
In-Reply-To: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>
Message-ID: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

There are still a couple of issues on the Fedora buildbot. Most of
them are caused by the absence of threading.

----------
components: Tests
keywords: buildbot
messages: 136890
nosy: skrah, tarek
priority: normal
severity: normal
status: open
title: test_packaging: failures --without-threads
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12180>
_______________________________________

From report at bugs.python.org  Wed May 25 22:13:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 20:13:53 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <E1QPKSm-0005db-Fi@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 742ff94cdd20 by Victor Stinner in branch '3.1':
Issue #12175: FileIO.readall() now raises a ValueError instead of an IOError if
http://hg.python.org/cpython/rev/742ff94cdd20

New changeset 745e373c0b8e by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12175: FileIO.readall() now raises a ValueError instead of
http://hg.python.org/cpython/rev/745e373c0b8e

New changeset 9051275a68fe by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12175: FileIO.readall() now raises a ValueError instead of
http://hg.python.org/cpython/rev/9051275a68fe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 22:18:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 20:18:17 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <E1QPKX2-00062I-Cr@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f2414bb35c96 by Victor Stinner in branch '2.7':
Issue #12175: FileIO.readall() now raises a ValueError instead of an IOError if
http://hg.python.org/cpython/rev/f2414bb35c96

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 22:20:03 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 25 May 2011 20:20:03 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hello,

on OpenBSD (arch: sparc64), when I run the regress tests, I have a SIGBUS error during the test_kqueue.py:

(gdb) run /tmp/test_kqueue.py
Starting program: /usr/local/bin/python2.7 /tmp/test_kqueue.py
testPair (__main__.TestKQueue) ...
Program received signal SIGBUS, Bus error.
PyMember_GetOne (addr=0x21007b72c "", l=0x211d2e9c8) at Python/structmember.c:128
128             v = PyLong_FromLongLong(*(PY_LONG_LONG *)addr);

I compiled Python 2.7.1 with debug symbols to help you, attached file is the gdb output (backtrace).

Don't hesitate to ask me if you need information.

Thanks.

----------
components: Tests
files: python2.7.1_sigbus_sparc64
messages: 136893
nosy: rpointel
priority: normal
severity: normal
status: open
title: SIGBUS error on OpenBSD (sparc64)
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file22115/python2.7.1_sigbus_sparc64

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed May 25 22:21:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 20:21:08 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1306354868.65.0.0253159211782.issue11109@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset 3e3cd0ed82bb by Senthil Kumaran in branch 'default':
> News entry for issue11109.
> http://hg.python.org/cpython/rev/3e3cd0ed82bb

Please try to format NEWS entries using "Issue #xxx: xxx" instead of "Issue #xxx - xxx".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Wed May 25 22:23:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 20:23:25 +0000
Subject: [issue12180] test_packaging: failures --without-threads
In-Reply-To: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>
Message-ID: <1306355005.96.0.186066553952.issue12180@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/issue12180>
_______________________________________

From report at bugs.python.org  Wed May 25 22:27:37 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Wed, 25 May 2011 20:27:37 +0000
Subject: [issue12161] StringIO AttributeError instead of ValueError after
	close..
In-Reply-To: <1306180961.98.0.624662608514.issue12161@psf.upfronthosting.co.za>
Message-ID: <1306355257.25.0.141743510681.issue12161@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Attached patch + test case.

Also tested cStringIO in 2.7 and io.StringIO in 3.2 and 3.3 tip and they aren't affected.

----------
keywords: +patch
nosy: +catalin.iacob
Added file: http://bugs.python.org/file22116/12161.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12161>
_______________________________________

From report at bugs.python.org  Wed May 25 22:43:05 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2011 20:43:05 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306356185.84.0.740458161376.issue12006@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not familiar with this module, so at the moment I just gave the patch a quick scan.  The approach looks OK to me.  Hopefully Alexander can review it.  In the meantime I think you should go ahead and work on tests and doc.  It is easier to do a detailed review when tests are included.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 22:53:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 20:53:58 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <E1QPL5Z-0000ye-CJ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4a7118cff1d3 by Victor Stinner in branch '3.1':
Issue #12175: RawIOBase.readall() now returns None if read() returns None.
http://hg.python.org/cpython/rev/4a7118cff1d3

New changeset fb29dc650d24 by Victor Stinner in branch '3.2':
(Merge 3.1) Issue #12175: RawIOBase.readall() now returns None if read()
http://hg.python.org/cpython/rev/fb29dc650d24

New changeset 325453be64ec by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12175: RawIOBase.readall() now returns None if read()
http://hg.python.org/cpython/rev/325453be64ec

New changeset 43a498da8680 by Victor Stinner in branch '2.7':
Issue #12175: RawIOBase.readall() now returns None if read() returns None.
http://hg.python.org/cpython/rev/43a498da8680

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 22:54:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 25 May 2011 20:54:40 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306356880.73.0.198304081561.issue12181@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It's an unaligned access:

addr=0x21007b72c

  case T_LONGLONG:
      v = PyLong_FromLongLong(*(PY_LONG_LONG *)addr);

sizeof(PY_LONG_LONG) == 8, but addr % 8 = 0x21007b72c % 8 == 4

----------
nosy: +charles-francois.natali

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed May 25 22:55:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 25 May 2011 20:55:32 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306356932.0.0.0640609138854.issue12181@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed May 25 22:56:45 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 25 May 2011 20:56:45 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306357005.14.0.208503208354.issue12006@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I'll try to give this a more  thorough review by the end of the week.  For now, just a nit-pick, but _calc_julian_from_V jumped at me as a really odd name.  Either "iso_to_julian" or "julian_from_iso" would be much clearer.  The patch also needs tests and documentation.

----------
assignee:  -> belopolsky
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Wed May 25 23:03:13 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 25 May 2011 21:03:13 +0000
Subject: [issue12180] test_packaging: failures --without-threads
In-Reply-To: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>
Message-ID: <1306357393.5.0.289078166575.issue12180@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

looking

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12180>
_______________________________________

From report at bugs.python.org  Wed May 25 23:03:35 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 25 May 2011 21:03:35 +0000
Subject: [issue12180] test_packaging: failures --without-threads
In-Reply-To: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>
Message-ID: <1306357415.27.0.572719287252.issue12180@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12180>
_______________________________________

From report at bugs.python.org  Wed May 25 23:15:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:15:07 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306358107.25.0.992301434255.issue12181@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Don't hesitate to ask me if you need information.

It looks like the crash occurs on r[0].data in testPair() of test_kqueue. Can you confirm this? Comment the line in test_kqueue.py to check if it works around the crash.

What is the size of intptr_t and "long long" types on your host? You can find this information in config.log if you compiled Python manually. Otherwise, use a dummy C script like:
--------------
int main() { return sizeof(long long); }
--------------
and
--------------
#include <stdint.h>
int main() { return sizeof(intptr_t); }
--------------
Compile the script, run it, and read the exitcode (e.g.g echo $? using bash).

Can you try to get the definition of the kevent structure? It should be in /usr/include/sys/event.h. And/or the offset of each field using the following C script (not tested):
-------------
#include <stdio.h>
#include <sys/event.h>
#include <stddef.h> /* For offsetof */

#ifndef offsetof
#define offsetof(type, member) ( (int) & ((type*)0) -> member )
#endif

struct kevent ev;

#define DUMP(field) printf("offset of " #field ": %u\n", offsetof(ev, field))

int main()
{
   DUMP(ident);
   DUMP(filter);
   DUMP(flags);
   DUMP(fflags);
   DUMP(data);
   DUMP(udata);
   return 0;
}
-------------

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed May 25 23:32:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:32:15 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306359135.61.0.370037680313.issue12175@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Attached patch [fileio_readall.patch] fixes both problems.

> Looks ok to me. Did you test under Windows?

Yes, test_io pass on Windows Vista 64 bits.

> Did you run some benchmarks?

Yes, see msg136853. Do you mean that I should not touch FileIO.readall() if it doesn't make it faster? (only 7% faster)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 23:42:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:42:32 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306359752.92.0.00303667123268.issue12175@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> You must Py_DECREF(all) first.
> Also, you should check that "all" is either None or a bytes object.

Right, fixed in bufferedreader_readall-2.patch. By the way, thanks for your reviews.

So, do you think that fileio_readall.patch and bufferedreader_readall-2.patch should be commited, or these changes are useless?

----------
Added file: http://bugs.python.org/file22117/bufferedreader_readall-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 23:44:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:44:12 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306359852.1.0.454944593056.issue12175@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22117/bufferedreader_readall-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 23:44:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:44:18 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306359858.2.0.572042992659.issue12175@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file22118/bufferedreader_readall-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 23:44:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:44:44 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306359884.41.0.270393287469.issue12175@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22109/bufferedreader_readall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 23:45:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:45:46 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306359946.88.0.449333271996.issue12175@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22107/fileio_readall_closed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 23:46:34 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 25 May 2011 21:46:34 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306359994.59.0.961681327959.issue12181@psf.upfronthosting.co.za>


rpointel <python at xiri.fr> added the comment:

> It looks like the crash occurs on r[0].data in testPair() of test_kqueue. Can you confirm this? Comment the line in test_kqueue.py to check if it works around the crash.

Yes, it does not crash if I comment this line.

> What is the size of intptr_t and "long long" types on your host?

size of intptr_t and "long long" is : 8.

> Can you try to get the definition of the kevent structure? It should be in /usr/include/sys/event.h. And/or the offset of each field using the following C script (not tested).

I have replaced this line of your program (because it failed to build):
#define DUMP(field) printf("offset of " #field ": %u\n", offsetof(ev, field))
by
#define DUMP(field) printf("offset of " #field ": %u\n", offsetof(struct kevent, field))

and I have:
                                                                                                                                                                                                       
offset of ident: 0
offset of filter: 4
offset of flags: 6
offset of fflags: 8
offset of data: 12
offset of udata: 16

Thanks a lot for your help,

Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Wed May 25 23:46:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:46:39 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306359999.77.0.481854138098.issue12175@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22108/rawiobase_readall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Wed May 25 23:46:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 21:46:44 +0000
Subject: [issue12180] test_packaging: failures --without-threads
In-Reply-To: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>
Message-ID: <E1QPLud-0005y6-27@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8aa1ae77cfe1 by Tarek Ziade in branch 'default':
Issue #12180: Fixed a few remaining errors in test_packaging when no threading.
http://hg.python.org/cpython/rev/8aa1ae77cfe1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12180>
_______________________________________

From report at bugs.python.org  Wed May 25 23:49:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 May 2011 21:49:46 +0000
Subject: [issue12177] re.match raises MemoryError
In-Reply-To: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>
Message-ID: <1306360186.17.0.842857186918.issue12177@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Confirmed. The test case quickly uses 8GB of memory.

----------
nosy: +ezio.melotti, pitrou, skrah
stage:  -> needs patch
versions: +Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12177>
_______________________________________

From report at bugs.python.org  Wed May 25 23:49:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:49:49 +0000
Subject: [issue12071] test_concurrent_futures.test_context_manager_shutdown()
	hangs on OpenIndiana
In-Reply-To: <1305296095.67.0.81105538299.issue12071@psf.upfronthosting.co.za>
Message-ID: <1306360189.56.0.284350972186.issue12071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Since it's a OOM issue, can we close?

Yes, I don't want to investigate, and I already changed the size of my swap partition, so I cannot reproduce the bug anymore.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12071>
_______________________________________

From report at bugs.python.org  Wed May 25 23:52:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 21:52:43 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <4DDCBC6E.5000703@egenix.com>
Message-ID: <1306360354.24449.1.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 25 mai 2011 ? 08:23 +0000, Marc-Andre Lemburg a ?crit :
> > Do we need an additional method? It seems that this reset() could
> > also be written encoder.encode('', final=True)
> 
> +1
> 
> I think that's a much more natural way to implement "finalize the
> encoding output without adding any data to it".

And so, reset() should discard the output? I can easily adapt my patch
to discard the output (but still call encreset() instead of decreset()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Wed May 25 23:52:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 May 2011 21:52:45 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306359752.92.0.00303667123268.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306360361.3562.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So, do you think that fileio_readall.patch and
> bufferedreader_readall-2.patch should be commited, or these changes
> are useless?

They should be committed.
Thank you :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Thu May 26 00:01:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 22:01:11 +0000
Subject: [issue12100] Incremental encoders of CJK codecs reset the codec
	at	each call to encode()
In-Reply-To: <1305673805.66.0.039322983909.issue12100@psf.upfronthosting.co.za>
Message-ID: <1306360871.19.0.235034835451.issue12100@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The initial problem (reset() at each call to .encode()) is fixed in Python 2.7, 3.1, 3.2 and 3.3.

I opened a new issue, #12171, for the second problem noticed by Armin (decreset vs encreset).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12100>
_______________________________________

From report at bugs.python.org  Thu May 26 00:06:43 2011
From: report at bugs.python.org (wrobell)
Date: Wed, 25 May 2011 22:06:43 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306361203.75.0.404628175261.issue3754@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

well, looking at the first comment, there is required more than simple read of the manual (i.e. missing config.guess/config.sub).

is anything else missing or required?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu May 26 00:17:52 2011
From: report at bugs.python.org (Victor Godoy Poluceno)
Date: Wed, 25 May 2011 22:17:52 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306361872.51.0.730108683418.issue3754@psf.upfronthosting.co.za>


Changes by Victor Godoy Poluceno <victorpoluceno at gmail.com>:


----------
nosy:  -victorpoluceno

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu May 26 00:22:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 22:22:48 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <E1QPMTX-0000b1-AS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 72c89daace57 by Victor Stinner in branch 'default':
Issue #12175: FileIO.readall() now only reads the file position and size once.
http://hg.python.org/cpython/rev/72c89daace57

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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12175>
_______________________________________

From report at bugs.python.org  Thu May 26 00:25:27 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 25 May 2011 22:25:27 +0000
Subject: [issue12177] re.match raises MemoryError
In-Reply-To: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>
Message-ID: <1306362327.46.0.151551812239.issue12177@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

This also raises MemoryError:

    re.match(r'()*?1', 'a1')

but none of these do:

    re.match(r'()+1', 'a1')
    re.match(r'()*1', 'a1')

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12177>
_______________________________________

From report at bugs.python.org  Thu May 26 00:28:43 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Wed, 25 May 2011 22:28:43 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306362523.44.0.790762805794.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

Thanks everyone, please take your time if there are more pressing issues; I'll get to work on tests and documentation in the mean time. I agree that '_calc_julian_from_V' is a bit strange. I was mimicking a similar helper function's name ('_calc_julian_from_U_or_W'), but perhaps that is no defense.

Also, I know the functionality is there with 'toisocalendar' and 'toisoweekday', but maybe %V and %u should be implemented for 'strftime' for completeness. Any thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 00:31:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2011 22:31:05 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <1306362665.49.0.256134759775.issue12171@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

cjk_encreset.patch: Fix multibytecodec.MultibyteIncrementalEncoder.reset(), call encreset() instead of decreset(). Improve also incremental encoder tests: reset the encoder using .encode('', final=True) and check the output.

I also prefer to reuse the existing API instead of changing reset() API just for a corner case.

----------
Added file: http://bugs.python.org/file22119/cjk_encreset.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Thu May 26 00:31:14 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 25 May 2011 22:31:14 +0000
Subject: [issue12180] test_packaging: failures --without-threads
In-Reply-To: <1306354171.25.0.816159764546.issue12180@psf.upfronthosting.co.za>
Message-ID: <1306362674.57.0.130353622184.issue12180@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

all good now

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12180>
_______________________________________

From report at bugs.python.org  Thu May 26 00:40:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2011 22:40:21 +0000
Subject: [issue12090] 3.2: build --without-threads fails
In-Reply-To: <1305568611.26.0.714455176679.issue12090@psf.upfronthosting.co.za>
Message-ID: <E1QPMkV-0002E5-Ua@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset bb8bb4db2bc5 by Stefan Krah in branch '3.2':
Issue #12090: backport 79fcd71d0356
http://hg.python.org/cpython/rev/bb8bb4db2bc5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12090>
_______________________________________

From report at bugs.python.org  Thu May 26 00:48:38 2011
From: report at bugs.python.org (Martin)
Date: Wed, 25 May 2011 22:48:38 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <1306363718.1.0.666302927388.issue12171@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

New cjk_encreset.patch looks good to me.

As with issue 12100 this likely wasn't reported before because decoders are robust against escape sequence oddities.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Thu May 26 01:42:29 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 May 2011 23:42:29 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <1306360354.24449.1.camel@marge>
Message-ID: <4DDD93D9.30909@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Le mercredi 25 mai 2011 ? 08:23 +0000, Marc-Andre Lemburg a ?crit :
>>> Do we need an additional method? It seems that this reset() could
>>> also be written encoder.encode('', final=True)
>>
>> +1
>>
>> I think that's a much more natural way to implement "finalize the
>> encoding output without adding any data to it".
> 
> And so, reset() should discard the output? I can easily adapt my patch
> to discard the output (but still call encreset() instead of decreset()).

I'm not sure what you mean by "discard the output".

Calling .reset() should still add the closing sequence to the output
buffer, if needed.

The purpose of .reset() is flush all data and put the codec into a
clean state (comparable to the state you get when you start using
it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Thu May 26 01:55:04 2011
From: report at bugs.python.org (Ralf W. Grosse-Kunstleve)
Date: Wed, 25 May 2011 23:55:04 +0000
Subject: [issue12182] pydoc.py integer division problem
In-Reply-To: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>
Message-ID: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>


New submission from Ralf W. Grosse-Kunstleve <rwgk at yahoo.com>:

The pydoc.HTMLRepr.multicolumn() method fails when using the Python command-line option -Qnew.
The attached patch inserts two slashes for floor division. (I think the same change was applied to Python 3 already.)

----------
components: Library (Lib)
files: pydoc_patch
messages: 136920
nosy: rwgk
priority: normal
severity: normal
status: open
title: pydoc.py integer division problem
versions: Python 2.7
Added file: http://bugs.python.org/file22120/pydoc_patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12182>
_______________________________________

From report at bugs.python.org  Thu May 26 01:58:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 May 2011 23:58:36 +0000
Subject: [issue10330] trace module doesn't work without threads
In-Reply-To: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>
Message-ID: <1306367916.06.0.0396711600191.issue10330@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

test_trace still fails on 2.7 on the no-threads bot:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%202.7/builds/22/steps/test/logs/stdio


Could you have a short look at the patch. I think it should be correct;
the tests pass.

----------
nosy: +skrah
Added file: http://bugs.python.org/file22121/issue10330-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10330>
_______________________________________

From report at bugs.python.org  Thu May 26 02:14:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 00:14:09 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <1306368849.68.0.326458647267.issue12171@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm not sure what you mean by "discard the output".
> 
> Calling .reset() should still add the closing sequence to the output
> buffer, if needed.

Incremental encoders don't have any buffer.

Python 3.3a0 (default:3c7792ec4547+, May 26 2011, 00:24:51) 
>>> import codecs

>>> enc=codecs.lookup('hz').incrementalencoder()
>>> enc.encode('\u8000')
b'~{R+'
>>> enc.reset()

>>> enc.encode('\u8000')
b'~{R+'
>>> enc.encode('', final=True)
b'~}'

>>> import io
>>> buffer=io.BytesIO()
>>> enc=codecs.lookup('hz').streamwriter(buffer)
>>> enc.write('\u8000')
>>> buffer.getvalue()
b'~{R+'
>>> enc.reset()
>>> buffer.getvalue()
b'~{R+~}'

IncrementalEncoder.reset() may mention that the output is discarded:

   .. method:: reset()

      Reset the encoder to the initial state. The output is discarded: 
      use the ``encode('', final=True)`` method to reset the encoder 
      and to get the output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Thu May 26 02:16:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 26 May 2011 00:16:42 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1306362523.44.0.790762805794.issue12006@psf.upfronthosting.co.za>
Message-ID: <BANLkTimNKOhrJmp7GEwSXieTAiJDQDVXeg@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, May 25, 2011 at 6:28 PM, Ashley Anderson <report at bugs.python.org> wrote:
>
> .. I agree that '_calc_julian_from_V' is a bit strange. I was mimicking a similar helper function's
> name ('_calc_julian_from_U_or_W'), but perhaps that is no defense.

This is a perfect defense.  Local consistency usually trumps global
conventions.  I only looked at the patch and did not see that other
function.  Please don't change the name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 03:24:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2011 01:24:43 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306373083.04.0.282090141546.issue12006@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It looks like strftime already support %V and %u (presumably if and only if the platform strftime does).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 04:37:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2011 02:37:21 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <E1QPQRs-0001ha-Aa@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f3446f08187a by Kurt B. Kaiser in branch '2.7':
IDLE: #6378: Further adjust idle.bat to start associated Python
http://hg.python.org/cpython/rev/f3446f08187a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Thu May 26 06:42:00 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 26 May 2011 04:42:00 +0000
Subject: [issue12183] Python does not support lutime() function
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

see
http://www.linuxquestions.org/questions/programming-9/utime-on-a-symbolic-link-743085/:
----------
Hello,
The API utime() is not available for symbolic links.
However, with kernel 2.6.22 lutimes() API allowed setting times on atime and mtime on symbolic links.
----------

Neither python 2.7 nor 3.4 support lutime() syscall.
So imlpementation of shutil.copy2() and shutil.copystat() under question for symlinks. Also it's not clear in documentation behaviour of these functions on symlinks.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 136928
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: Python does not support lutime() function
type: feature request
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12183>
_______________________________________

From report at bugs.python.org  Thu May 26 06:46:06 2011
From: report at bugs.python.org (EungJun Yi)
Date: Thu, 26 May 2011 04:46:06 +0000
Subject: [issue12177] re.match raises MemoryError
In-Reply-To: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>
Message-ID: <1306385166.89.0.144881916826.issue12177@psf.upfronthosting.co.za>


EungJun Yi <semtlenori at gmail.com> added the comment:

This also raises in 2.6.5

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match('()+?1', 'a1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/re.py", line 137, in match
    return _compile(pattern, flags).match(string)
MemoryError

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12177>
_______________________________________

From report at bugs.python.org  Thu May 26 07:13:14 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 26 May 2011 05:13:14 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1306386794.52.0.384762581668.issue11109@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Victor - Sure, I understand Issue #xxx: desc must be useful while generation reST docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Thu May 26 07:19:53 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 26 May 2011 05:19:53 +0000
Subject: [issue12184] socketserver.ForkingMixin collect_children routine needs
	to collect only it's children
In-Reply-To: <1306387193.28.0.997527138067.issue12184@psf.upfronthosting.co.za>
Message-ID: <1306387193.28.0.997527138067.issue12184@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

socketserver.ForkingMixin class has a collect_children method, that waits for the children to exit.
But, that waits for any child process and not just the ones spawned the socketserver alone.

            try:
                pid, status = os.waitpid(0, 0)
            except os.error:
                pid = None

This is performance lag and can be improved. The collect_children can only wait/collect it's own children.

----------
messages: 136931
nosy: orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: socketserver.ForkingMixin collect_children routine needs to collect only it's children
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12184>
_______________________________________

From report at bugs.python.org  Thu May 26 07:21:02 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 26 May 2011 05:21:02 +0000
Subject: [issue12184] socketserver.ForkingMixin collect_children routine needs
	to collect only it's children
In-Reply-To: <1306387193.28.0.997527138067.issue12184@psf.upfronthosting.co.za>
Message-ID: <1306387262.32.0.568675059433.issue12184@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +charles-francois.natali

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12184>
_______________________________________

From report at bugs.python.org  Thu May 26 07:35:02 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 26 May 2011 05:35:02 +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: <1306388102.99.0.835334806859.issue12183@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Python 3.3 (as yet unreleased) supports the lutimes function:
  http://docs.python.org/dev/py3k/library/os.html#os.lutimes
Python 2.7 is not getting any more features so it will not be added.

I'm changing the title to the second part of your question, documenting the behaviour of shutil.copy2 and copytree.

----------
nosy: +rosslagerwall
title: Python does not support lutime() function -> Document behaviour of shutil.copy2 and copystat with symlinks
versions: +Python 3.1, Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12183>
_______________________________________

From report at bugs.python.org  Thu May 26 07:52:58 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 05:52:58 +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: <1306389178.81.0.878003331983.issue12183@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/issue12183>
_______________________________________

From report at bugs.python.org  Thu May 26 07:58:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 05:58:03 +0000
Subject: [issue12182] pydoc.py integer division problem
In-Reply-To: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>
Message-ID: <1306389483.9.0.978704499421.issue12182@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/issue12182>
_______________________________________

From report at bugs.python.org  Thu May 26 08:28:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 May 2011 06:28:16 +0000
Subject: [issue12182] pydoc.py integer division problem
In-Reply-To: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>
Message-ID: <1306391296.37.0.0667726718342.issue12182@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12182>
_______________________________________

From report at bugs.python.org  Thu May 26 08:29:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 May 2011 06:29:34 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1306391374.34.0.546881380431.issue12174@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +jnoller, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Thu May 26 08:49:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 06:49:53 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1306392593.62.0.0969517763371.issue12164@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
keywords: +patch
nosy: +petri.lehtinen
Added file: http://bugs.python.org/file22122/str_translate_docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12164>
_______________________________________

From report at bugs.python.org  Thu May 26 09:37:59 2011
From: report at bugs.python.org (Justin Warkentin)
Date: Thu, 26 May 2011 07:37:59 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1306395479.8.0.0741408867605.issue11109@psf.upfronthosting.co.za>


Justin Warkentin <justin.warkentin at gmail.com> added the comment:

Sorry, I haven't had a chance to look at this in a couple days. I've been very busy with work. I'm not sure exactly how to write the test for this, so I don't know that I'd be much help there.

One last thing, I was just looking through the commits and I noticed in the NEWS update (http://hg.python.org/cpython/rev/3e3cd0ed82bb/) you have my name as Justin Wark. The last name is actually Warkentin, I just didn't have anything showing that. That's my fault, sorry. I just updated my profile to show my full name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11109>
_______________________________________

From report at bugs.python.org  Thu May 26 10:01:34 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 08:01:34 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1306396894.08.0.754590039997.issue12157@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/issue12157>
_______________________________________

From report at bugs.python.org  Thu May 26 11:07:45 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 09:07:45 +0000
Subject: [issue12161] StringIO AttributeError instead of ValueError after
	close..
In-Reply-To: <1306180961.98.0.624662608514.issue12161@psf.upfronthosting.co.za>
Message-ID: <1306400865.42.0.309814045132.issue12161@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I tested the patch on current 2.7 tip. It works and looks good to me.

----------
nosy: +benjamin.peterson, petri.lehtinen, pitrou, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12161>
_______________________________________

From report at bugs.python.org  Thu May 26 11:51:41 2011
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 26 May 2011 09:51:41 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306403501.87.0.561891588007.issue11969@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Why is this still marked as "test needed"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Thu May 26 11:54:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 26 May 2011 09:54:12 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306403652.47.0.542433272841.issue11969@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The test should be a diff against Lib/test/test_multiprocessing.py that adds a unit test.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Thu May 26 12:54:36 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 10:54:36 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306407276.13.0.319383794436.issue12082@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Should the .pyc/.pyo file writing be disabled altogether if stat() and/or fstat() is not available. In this case, there's no way to check mtimes, right?

----------
nosy: +brett.cannon, ncoghlan, petri.lehtinen
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Thu May 26 13:04:59 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 11:04:59 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306407899.51.0.383948889212.issue12085@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

IMO it should be explained in a comment why getattr is used instead of just self._child_created. Otherwise the patch looks good and useful.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 13:07:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 11:07:49 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306408069.49.0.56566457867.issue12085@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We can use a class attribute to set the attribute before calling __init__:

diff --git a/Lib/subprocess.py b/Lib/subprocess.py
--- a/Lib/subprocess.py
+++ b/Lib/subprocess.py
@@ -664,6 +664,8 @@ _PLATFORM_DEFAULT_CLOSE_FDS = object()
 
 
 class Popen(object):
+    _child_created = False
+
     def __init__(self, args, bufsize=0, executable=None,
                  stdin=None, stdout=None, stderr=None,
                  preexec_fn=None, close_fds=_PLATFORM_DEFAULT_CLOSE_FDS,

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 13:09:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 11:09:14 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1306408069.49.0.56566457867.issue12085@psf.upfronthosting.co.za>
Message-ID: <20110526110913.GH7580@colossus>


Petri Lehtinen <petri at digip.org> added the comment:

STINNER Victor wrote:
> We can use a class attribute to set the attribute before calling __init__:

True, this is clever. Will you commit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 13:11:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 11:11:21 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306408281.38.0.294746294068.issue12085@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> True, this is clever. Will you commit?

I'm not sure that it's the pythonic way to solve such problem. Can you work on a patch including a test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 13:20:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 11:20:27 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306408827.87.0.144035560533.issue12085@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> I'm not sure that it's the pythonic way to solve such problem. Can you work on a patch including a test?

Yeah, getattr() might be more Pythonic indeed.

How can this be tested? According to the initial report, exceptions raised in __del__ seem to be ignored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 13:29:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 11:29:47 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306409387.36.0.925174292339.issue12082@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Does your filesystem store the modification time? Why don't you have/want fstat()? Do you have stat() or a similar function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Thu May 26 13:38:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2011 11:38:48 +0000
Subject: [issue12182] pydoc.py integer division problem
In-Reply-To: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>
Message-ID: <E1QPYtl-0006fG-Ep@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7724b53510c4 by Victor Stinner in branch '2.7':
Close #12182: Fix pydoc.HTMLDoc.multicolumn() if Python uses the new (true)
http://hg.python.org/cpython/rev/7724b53510c4

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12182>
_______________________________________

From report at bugs.python.org  Thu May 26 13:39:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 11:39:12 +0000
Subject: [issue12182] pydoc.py integer division problem
In-Reply-To: <1306367704.38.0.144213829983.issue12182@psf.upfronthosting.co.za>
Message-ID: <1306409952.05.0.962574314298.issue12182@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch applied, thanks for your patch!

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12182>
_______________________________________

From report at bugs.python.org  Thu May 26 13:43:09 2011
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 26 May 2011 11:43:09 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <1306410189.68.0.133911363878.issue12171@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

+1 on the documentation changes.

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Thu May 26 13:59:23 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 26 May 2011 11:59:23 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

http://docs.python.org/library/decimal.html

In 9.4.2, "Decimal objects", some of the methods mention the first and second parameters, when really it should be "self" and the argument, usually named "other" and sometimes something more specific. These include:

compare_total
copy_sign
next_toward
quantize (argument is exp)
rotate
scaleb
shift

It looks this is left over from where the same-named functions are described in the "Context objects" section.

----------
assignee: docs at python
components: Documentation
messages: 136947
nosy: docs at python, eric.smith
priority: normal
severity: normal
status: open
title: Decimal documentation lists "first" and "second" arguments, should be "self" and "other"
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Thu May 26 14:00:02 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Thu, 26 May 2011 12:00:02 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306411202.07.0.610064018463.issue12085@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

> We can use a class attribute to set the attribute before calling __init__

Ah, yes, I thought about adding a class attribute as well, but the class currently does not have any and initializes instance attributes to default values in __init__, so I chose getattr.

> How can this be tested? According to the initial report, exceptions raised in __del__ seem to be ignored.

Exceptions raised in __del__ are printed to sys.stderr, even if it has been reassigned by Python code:

>>> import sys, io, subprocess
>>> sys.stderr = io.StringIO()
>>> subprocess.Popen(fdsa=1)
>>> sys.stderr.getvalue()
'Exception AttributeError: "\'Popen\' object has no attribute \'_child_created\'" in <bound method Popen.__del__ of <subprocess.Popen object at 0x1006ee710>> ignored\nTraceback (most recent call last):\n  File "<stdin>", line 1, in <module>\nTypeError: __init__() got an unexpected keyword argument \'fdsa\'\n'

test_generators.py already uses this trick in a test similar to what would be needed for this issue around line 1856.

Should I attempt to modify my patch to include a comment and a test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 14:01:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 12:01:50 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306411310.33.0.208574291929.issue12085@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Should I attempt to modify my patch to include a comment and a test?

Yes please, you can use support.captured_stderr() tool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 14:03:07 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 26 May 2011 12:03:07 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1306411202.07.0.610064018463.issue12085@psf.upfronthosting.co.za>
Message-ID: <20110526120305.GI7580@colossus>


Petri Lehtinen <petri at digip.org> added the comment:

Oleg Oshmyan wrote:
> Should I attempt to modify my patch to include a comment and a test?

Absolutely, go ahead if it's not too much trouble.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 14:20:02 2011
From: report at bugs.python.org (stefanholek)
Date: Thu, 26 May 2011 12:20:02 +0000
Subject: [issue12186] readline.replace_history_item still leaks memory
In-Reply-To: <1306412402.14.0.859641157612.issue12186@psf.upfronthosting.co.za>
Message-ID: <1306412402.14.0.859641157612.issue12186@psf.upfronthosting.co.za>


New submission from stefanholek <stefan at epy.co.at>:

This is a continuation of issue #9450.

The 'data' element of a history entry may point to an undo list for the entry. When freeing the entry the associated undo list must be freed as well, and 'free(data)' alone does not cut it. I have not found any other use of the 'data' element in all of GNU Readline, so it is safe to assume it is either NULL or an undo list.

diff --git a/rl/readline.c b/rl/readline.c
index 26ac1e2..c8efd5b 100644
--- a/rl/readline.c
+++ b/rl/readline.c
@@ -541,8 +541,18 @@
 static void
 _py_free_history_entry(HIST_ENTRY *entry)
 {
-       histdata_t data = free_history_entry(entry);
-       free(data);
+       UNDO_LIST *undo_list;
+       UNDO_LIST *release;
+
+       /* A history entry may have an undo_list attached */
+       undo_list = (UNDO_LIST *)free_history_entry(entry);
+       while (undo_list) {
+               release = undo_list;
+               undo_list = undo_list->next;
+               if (release->what == UNDO_DELETE)
+                       free(release->text);
+               free(release);
+       }
 }

----------
components: Library (Lib)
messages: 136951
nosy: stefanholek
priority: normal
severity: normal
status: open
title: readline.replace_history_item still leaks memory
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12186>
_______________________________________

From report at bugs.python.org  Thu May 26 14:39:49 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Thu, 26 May 2011 12:39:49 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306413589.93.0.208348666351.issue12085@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

Here is a new patch; please take a look. Do I understand correctly that I should now remove the old one?

----------
Added file: http://bugs.python.org/file22123/_child_created_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 14:46:23 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 26 May 2011 12:46:23 +0000
Subject: [issue12184] socketserver.ForkingMixin collect_children routine needs
	to collect only it's children
In-Reply-To: <1306387193.28.0.997527138067.issue12184@psf.upfronthosting.co.za>
Message-ID: <1306413983.8.0.405139663003.issue12184@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

In the common case, I don't think that the os.waitpid(0, 0) is the hot spot, but rather this:

for child in self.active_children:
    os.waitpid(child, os.WNOHANG)

It's called every time, and it's O(number of active children).

os.waitpid(0, 0) is only called when max_children (40) is reached. Also, I'm not sure why it's called without WNOHANG, because that means that we will block until active_children falls below max_children. That's an arbitrary limit, especially since it's not documented.

I've written a first draft patch using process group, that removes active_children and max_children.
The only slightly tricky part is the call to setpgid from the child and from the parent, to avoid a race where the child could try to join a stale PGID.
Note that I assume that setpgid is available on every Unix, since according to http://pubs.opengroup.org/onlinepubs/007908799/xsh/setpgid.html , it's "Derived from the POSIX.1-1988 standard".
Also, according to buildbots' configure logs, it's available everywhere.

----------
keywords: +patch
Added file: http://bugs.python.org/file22124/ss_wait_group.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12184>
_______________________________________

From report at bugs.python.org  Thu May 26 14:46:52 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Thu, 26 May 2011 12:46:52 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306414012.9.0.664841861946.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

Uploaded patch adding unit tests for %V and %u. Patch is against python2.7

----------
Added file: http://bugs.python.org/file22125/test_strptime.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 14:52:14 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Thu, 26 May 2011 12:52:14 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306414334.18.0.656939333098.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

Patch by aganders3 doesn't compile. Added comments in review of his patch. Adding a patch against python2.7 with my changes, which pass all unit tests posted previously.

----------
Added file: http://bugs.python.org/file22126/_strptime.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 15:04:40 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Thu, 26 May 2011 13:04:40 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306415080.93.0.318420468423.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

Documentation (I have no idea how to create a patch for this):

%V ISO week number of the year (Monday as the first day of the week) as a decimal number (01-53). The week containing January 4 is week 1;
the previous week is the last week of the previous year.

%u ISO weekday (Monday as the first day of the week) as a decimal number (1-7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 15:11:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 26 May 2011 13:11:12 +0000
Subject: [issue12184] socketserver.ForkingMixin collect_children routine needs
	to collect only it's children
In-Reply-To: <1306387193.28.0.997527138067.issue12184@psf.upfronthosting.co.za>
Message-ID: <1306415472.73.0.844858135312.issue12184@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Some precisions:
1) Of course, if a handler changes its process group through setsid/setpgrp, it won't be waited on.
2) If a handler running on behalf of a process which is the current process group leader calls setsid, it will get an EPERM error.
I don't think anyone is using that, but I'd rather make it clear.
The only way I can think of to alleviate 2 would be to spawn a dummy process that would just be used as process group leader (and since it would keep running, no need to re-allocate a new PGID when worker processes exit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12184>
_______________________________________

From report at bugs.python.org  Thu May 26 15:32:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 13:32:21 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Polling should be avoided when it's possible. For subprocess.wait(), we can do something with signals (SIGCHLD and/or SIGCLD).

sigtimedwait() can be used to wait a the "a child process terminated" with a timeout, but not wait a specific process (so we may use a loop). sigtimedwait() doesn't call the signal handler, and so it changes the behaviour if the parent process has a signal handler for SIGCHLD/SIGCLD.

If sigtimedwait() is not available, we may use a signal handler. For example, we can use the "wakeup fd" tool of the signal module. Problem: the parent program may already have such handler / use "wakeup fd". We should at least restore the previous signal handler when we are done.

----------
assignee: pitrou
components: Library (Lib)
messages: 136958
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: subprocess.wait() with a timeout uses polling on POSIX
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Thu May 26 15:41:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 13:41:37 +0000
Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX
In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za>
Message-ID: <1306417297.5.0.593279321062.issue12187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On Linux, the clone() syscall allows the change the signal send by the child to the parent when it terminates. It's also possible to choose to not send a signal when at child exit... But I don't think that subprocess uses such options ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________

From report at bugs.python.org  Thu May 26 15:44:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2011 13:44:34 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306417474.54.0.664028816305.issue12006@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since this is a new feature it can only go into 3.3.

Documentation is in the Doc subdirectory of a checkout, and is in the form of *.rst files.  Modify the appropriate .rst file, and the doc update will be included in the patch you generate.  If you wish to test your doc patch, execute 'make html' in the Doc subdirectory, which will pull in the appropriate software and build the docs in a Doc/build/html subdirectory.

Ashely's patch worked for me on 3.3 in a minimal test; I haven't looked it it further at this point.

Thanks for reviewing and for working on the unit tests and docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 15:47:14 2011
From: report at bugs.python.org (Fabio Zadrozny)
Date: Thu, 26 May 2011 13:47:14 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1306417634.74.0.942777109694.issue11798@psf.upfronthosting.co.za>


Fabio Zadrozny <fabioz at users.sourceforge.net> added the comment:

So Michal, it seems no objections were raised?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu May 26 15:54:38 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 26 May 2011 13:54:38 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306418078.88.0.257316413286.issue3754@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

as well, by default one experiences

checking for /dev/ptmx... not set
configure: error: set ac_cv_file__dev_ptmx to yes/no in your CONFIG_SITE file when cross compiling


the workaround:

1. create config.site file with the following lines

     ac_cv_file__dev_ptmx=no
     ac_cv_file__dev_ptc=no

2. run configure script as: CONFIG_SITE=config.site ./configure --host...

would be it ok if i add appropriate options for /dev/ptmx and /dev/ptc to this patch so we do not have to play with config.site file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu May 26 15:55:58 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 26 May 2011 13:55:58 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306418158.95.0.440425185794.issue3754@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

next question. when starting compilation i am getting

In file included from Include/Python.h:50,
                 from ./Modules/python.c:3:
Include/pyport.h:257:13: error: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG"
make: *** [Modules/python.o] Error 1

how to deal with above?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu May 26 15:57:57 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Thu, 26 May 2011 13:57:57 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306418277.65.0.939054581718.issue12085@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

Looking at my own patch, I've noticed that the comment I added to Popen.__del__ doesn't sound quite right to me in terms of language and doesn't end in a full stop while all other comments in the same method do. Am I being too picky? I can't really think of a wording that would sound any better without it also being awkward though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Thu May 26 16:21:59 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 26 May 2011 14:21:59 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1306417474.54.0.664028816305.issue12006@psf.upfronthosting.co.za>
Message-ID: <BANLkTinuw=uieWfMcQV3f8=SVHKCJ6ExbA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, May 26, 2011 at 9:44 AM, R. David Murray <report at bugs.python.org> wrote:
..
> Documentation is in the Doc subdirectory of a checkout, and is in the form of *.rst files. ?Modify the appropriate .rst file,

More specifically, strftime/strptime directives are listed in a table
inside the the Doc/library/datetime.rst file.  Note that the narrative
before the table says that only C89 standard codes are listed and I
don't think %V and %u are standard.  Check if there is an applicable
standard for them - C99 and POSIX define more codes that C89.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 16:23:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 14:23:47 +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: <1306419827.64.0.510605744775.issue12169@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
keywords: +easy
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12169>
_______________________________________

From report at bugs.python.org  Thu May 26 16:39:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 14:39:35 +0000
Subject: [issue12154] PyDoc Partial Functions
In-Reply-To: <1306142131.82.0.401706336814.issue12154@psf.upfronthosting.co.za>
Message-ID: <1306420775.95.0.421402371451.issue12154@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This section should help: http://docs.python.org/dev/library/inspect#classes-and-functions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12154>
_______________________________________

From report at bugs.python.org  Thu May 26 16:45:29 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 26 May 2011 14:45:29 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1306421129.58.0.805776726578.issue11798@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sure, let's do it. Fabio, care to provide patch with tests and doc changes? (For 3.3.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu May 26 16:51:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2011 14:51:44 +0000
Subject: [issue11591] "python -S" should be robust against e.g. "from site
	import addsitedir"
In-Reply-To: <1300391220.57.0.0581670249847.issue11591@psf.upfronthosting.co.za>
Message-ID: <E1QPbuZ-0007Dd-8x@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6ee5443773cb by ?ric Araujo in branch 'default':
Also add versionchanged directive to the function doc (#11591)
http://hg.python.org/cpython/rev/6ee5443773cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11591>
_______________________________________

From report at bugs.python.org  Thu May 26 16:54:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 26 May 2011 14:54:28 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306421668.75.0.922701471764.issue12181@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

OpenBSD's struct kevent definition looks fishy:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/event.h?rev=1.15;content-type=text%2Fplain

struct kevent {
	u_int		ident;		/* identifier for this event */
	short		filter;		/* filter for event */
	u_short		flags;
	u_int		fflags;
	int		data;
	void		*udata;		/* opaque user data identifier */
};

ident and data should be uintptr_t/intptr_t, no wonder this breaks on 64-bit. See for example FreeBSD's header: http://gitorious.org/freebsd/freebsd/blobs/4369b8d3fe19ee9540bfda1bb5f3db6208ff4c91/sys/sys/event.h

----------
nosy:  -mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Thu May 26 16:55:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2011 14:55:01 +0000
Subject: [issue9435] test_distutils fails without zlib
In-Reply-To: <1280590585.97.0.266735291444.issue9435@psf.upfronthosting.co.za>
Message-ID: <E1QPbxk-0007TP-3H@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d5572fd3b768 by ?ric Araujo in branch '2.7':
Make test_distutils pass without zlib (fixes #9435)
http://hg.python.org/cpython/rev/d5572fd3b768

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9435>
_______________________________________

From report at bugs.python.org  Thu May 26 16:56:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 14:56:54 +0000
Subject: [issue9435] test_distutils fails without zlib
In-Reply-To: <1280590585.97.0.266735291444.issue9435@psf.upfronthosting.co.za>
Message-ID: <1306421814.65.0.270052930447.issue9435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can?t reproduce in 3.x, fixed in 2.7.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9435>
_______________________________________

From report at bugs.python.org  Thu May 26 16:57:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2011 14:57:10 +0000
Subject: [issue12161] StringIO AttributeError instead of ValueError after
	close..
In-Reply-To: <1306180961.98.0.624662608514.issue12161@psf.upfronthosting.co.za>
Message-ID: <E1QPbzp-0007lp-HF@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 720804a91c01 by Benjamin Peterson in branch '2.7':
raise an ValueError in getvalue() on closed StringIO (closes #12161)
http://hg.python.org/cpython/rev/720804a91c01

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12161>
_______________________________________

From report at bugs.python.org  Thu May 26 16:59:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 14:59:20 +0000
Subject: [issue12178] csv writer doesn't escape escapechar
In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za>
Message-ID: <1306421960.63.0.936675229981.issue12178@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  It would be best if you could attach files as plain text instead of archives.

----------
components: +Extension Modules -None
nosy: +eric.araujo, skip.montanaro
versions: +Python 3.1, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12178>
_______________________________________

From report at bugs.python.org  Thu May 26 17:53:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 15:53:47 +0000
Subject: [issue9654] merge PC/getpathp.c into Modules/getpath.c
In-Reply-To: <1282340469.22.0.133345899544.issue9654@psf.upfronthosting.co.za>
Message-ID: <1306425227.47.0.227672895764.issue9654@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, haypo
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9654>
_______________________________________

From report at bugs.python.org  Thu May 26 17:55:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 15:55:40 +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: <1306425340.19.0.0533110179545.issue9561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Definitely.  We can fix real bugs in distutils, but sometimes it?s best to avoid disruptive changes and let distutils with its buggy behavior and let the packaging module have the best behavior.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Thu May 26 18:04:02 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 May 2011 16:04:02 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1306425340.19.0.0533110179545.issue9561@psf.upfronthosting.co.za>
Message-ID: <4DDE79E4.2080907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Definitely.  We can fix real bugs in distutils, but sometimes it?s best to avoid disruptive changes and let distutils with its buggy behavior and let the packaging module have the best behavior.

This is a real bug, since we agreed long ago that distutils should
read and write files using the UTF-8 encoding.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Thu May 26 18:07:48 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Thu, 26 May 2011 16:07:48 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306426068.2.0.122157721734.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

When trying to add cases for %V and %u in the tests, I ran into an issue of year ambiguity. The problem comes when the ISO year does not match the Gregorian year for a given date. I think this should be fixed by implementing the %G directive (ISO year, which is present in strftime) as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 18:15:14 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 26 May 2011 16:15:14 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1306426068.2.0.122157721734.issue12006@psf.upfronthosting.co.za>
Message-ID: <BANLkTim+Db8sdTrDv=Qv4nVfDrCG7iYP5w@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, May 26, 2011 at 12:07 PM, Ashley Anderson
<report at bugs.python.org> wrote:
> I think this should be fixed by implementing the %G directive (ISO year, which is present in strftime) as well.

Correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 18:21:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 16:21:27 +0000
Subject: [issue9654] merge PC/getpathp.c into Modules/getpath.c
In-Reply-To: <1282340469.22.0.133345899544.issue9654@psf.upfronthosting.co.za>
Message-ID: <1306426887.83.0.601865956656.issue9654@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I propose to merge both files, this would ease maintenance
> and understanding of how these paths are determined.

You mean to have only one function? I would prefer to keep two functions, but one should call the another one :) (you should factorize the code)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9654>
_______________________________________

From report at bugs.python.org  Thu May 26 18:29:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2011 16:29:03 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306421668.75.0.922701471764.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306427336.5619.2.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 26 mai 2011 ? 14:54 +0000, Charles-Fran?ois Natali a ?crit :
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
> 
> OpenBSD's struct kevent definition looks fishy:
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/event.h?rev=1.15;content-type=text%2Fplain
> 
> struct kevent {
> 	u_int		ident;		/* identifier for this event */
> 	short		filter;		/* filter for event */
> 	u_short		flags;
> 	u_int		fflags;
> 	int		data;
> 	void		*udata;		/* opaque user data identifier */
> };
> 
> ident and data should be uintptr_t/intptr_t

ident and data are not pointers, I suppose that T_UINT and T_INT should
be used instead of T_UINTPTR_T and  T_INTPTR_T. intptr_t is bigger than
an int on a 64 bits system (void*: 64 bits, int: 32 bits).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Thu May 26 18:43:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 16:43:07 +0000
Subject: [issue10766] optparse uses %s in gettext calls
In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za>
Message-ID: <1306428187.01.0.183571873288.issue10766@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> 
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10766>
_______________________________________

From report at bugs.python.org  Thu May 26 18:44:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 16:44:54 +0000
Subject: [issue11664] Add patch method to unittest.TestCase
In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za>
Message-ID: <1306428294.76.0.0950941383554.issue11664@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There?s also test.support.swap_attr...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11664>
_______________________________________

From report at bugs.python.org  Thu May 26 18:46:31 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 26 May 2011 16:46:31 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1306428391.74.0.578633396677.issue8777@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu May 26 18:49:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2011 16:49:44 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1306428584.71.0.870020254372.issue10424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would remove the docstring from the new test class...if more tests of message content are added that docstring won't be accurate.  It really isn't needed.  (Also, shouldn't the test method be named test_missingarguments?)

I would also like to see a test where there are optional non-option arguments (nargs='?'), where you test that the optional one does *not* appear in the message.  That'll give you a second test method, making that test class a *little* less trivial :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Thu May 26 18:52:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 16:52:09 +0000
Subject: [issue10645] Remove egg-info files in stdlib
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1306428729.06.0.691609867989.issue10645@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The egg-info file for Python itself can go, but what about wsgiref.egg-info?  It was included in 2.5 too to preserve compatibility with code using pkg_resources.require instead of regular import.  I?d like to remove it too: it?s not needed anymore with the new standards, and I don?t think there?s a backward compat issue.  There shouldn?t be 3.x code out there using this call, since all 3.x versions have had wsgiref in the stdlib.  The only compat issue could be for some 2.x codebase relying on the egg-info file and being converted to Python 3.3: if we remove the file, people would have to remove the pkg_resources.require call.  I would argue in favor of the removal: people can assume that wsgiref is in the stdlib if they target 2.5+ or 3.x, and if they do use the require call, then removing it is just another tiny step in the conversion process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Thu May 26 18:53:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 May 2011 16:53:59 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1306428839.32.0.0528111384648.issue11342@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing after no reply.  If someone can reproduce the bug, please say so and reopen.

----------
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Thu May 26 19:01:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2011 17:01:41 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306429301.21.0.604014200117.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What is not-a-charset?

I apparently misunderstood what normalize_encodings does.  It isn't doing a lookup in the codecs registry and returning the canonical name for the codec.  Does that mean we actually have to fetch the codec in order to get the canonical name?  I suspect so, and that is probably OK, since in most cases the codec is eventually going to get called while processing the email that triggered the ALIASES lookup.

I also notice that there is a table of aliases in the codec module documentation, so that will need to be updated as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Thu May 26 19:12:29 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 26 May 2011 17:12:29 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306429949.33.0.957555814067.issue12042@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


Added file: http://bugs.python.org/file22127/issue12042_31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Thu May 26 19:12:50 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 26 May 2011 17:12:50 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306429970.15.0.82569129307.issue12042@psf.upfronthosting.co.za>


Changes by Jordan Stadler <jordan.stadler at gmail.com>:


Added file: http://bugs.python.org/file22128/issue12042_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Thu May 26 19:17:12 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 26 May 2011 17:17:12 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306430232.75.0.323638534886.issue12042@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

Alright, patches are up for 3.1 and 3.2. I'm not sure if I can just make one for the 3.x's so I made both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Thu May 26 19:43:37 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 26 May 2011 17:43:37 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1306431817.89.0.993812274207.issue10424@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Done.

----------
Added file: http://bugs.python.org/file22129/issue10424_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Thu May 26 19:45:51 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 26 May 2011 17:45:51 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306431951.28.0.0111112269967.issue3754@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

looking into configure.in the above fails due to following check

  AC_MSG_CHECKING(for %lld and %llu printf() format support)

the check compiles and tries to _run_ a bit of software to determine lld/llu support.

that of course fails (we are cross compiling). this is similar problem to ptmx/ptc problem (we do not know if host have support for ptmx/ptc).

i wonder if the following would be acceptable

1. if in cross compilation mode, the configure.in could load config-cross.site.
2. the config-cross.site would define variables for ptmx/ptc, long long format and other checks which consist of running code snippets
3. appropriate checks (i.e. ptmx/ptc, lld/llu) would not be run in cross compilation mode. variables from config-cross.site would be used instead.
4. it would be a developer responsibility to set appropriate values for his platform in config-cross.site file.

does above sound like a solution?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu May 26 19:47:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 26 May 2011 17:47:43 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306427336.5619.2.camel@marge>
Message-ID: <BANLkTikKQH0Nu-sLJLCUGrMxkm5k=H9N4A@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> ident and data are not pointers,

That's not the point.
struct kevent declaration should be the following:

struct kevent {
        uintptr_t ident;        /* identifier for this event */
        short     filter;       /* filter for event */
        u_short   flags;        /* action flags for kqueue */
        u_int     fflags;       /* filter flag value */
        intptr_t  data;         /* filter data value */
        void      *udata;       /* opaque user data identifier */
};

If this doesn't match, you'll unpack garbage when extracting members,
and since it's an unaligned access, you can even get a SIGBUS (looks
like sparc64 doesn't allow unaligned access).

> I suppose that T_UINT and T_INT should be used instead of T_UINTPTR_T and ?T_INTPTR_T.

Yes, we could do that on OpenBSD, but that's definitely an OpenBSD bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Thu May 26 19:57:44 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 May 2011 17:57:44 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1306429301.21.0.604014200117.issue8898@psf.upfronthosting.co.za>
Message-ID: <4DDE948A.7020208@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> What is not-a-charset?
>
> I apparently misunderstood what normalize_encodings does.  It isn't doing a lookup in the codecs registry and returning the canonical name for the codec.  Does that mean we actually have to fetch the codec in order to get the canonical name?  I suspect so, and that is probably OK, since in most cases the codec is eventually going to get called while processing the email that triggered the ALIASES lookup.
> 
> I also notice that there is a table of aliases in the codec module documentation, so that will need to be updated as well.

As far as the aliases.py part of the patch goes, I'm fine with that
since it corrects a few real bugs and adds the missing Latin-N
codec names.

Regarding using this table in the email package, I'm not really
clear on what you want to achieve.

If you are looking for a way to determine whether Python has a codec
installed for a certain charset name, then codecs.lookup() will
tell you this (and it also applies all the aliasing and normalization
needed).

If you want to avoid the actual codec module import (codecs.lookup()
imports the module), you can mimic the logic used by the lookup function
of the encodings package. Not sure, whether that's worth it, though,
since it is rather likely that you're going to use the codec you've
just looked up soon after the test and codecs.lookup() caches the
found codecs.

If you want to convert an arbitrary encoding name to a registered
standard IANA MIME charset name, then the aliases.py module is not
going to be of much help, since we are using our own canonical
names which do not necessarily map to the MIME charset names.

You'd have to add a new mime_alias map to the email package
for that. I'd suggest to use the same approach as for the
aliases.py module, which is to first normalize the encoding
name using normalize_encoding() and then running that through
the mime_alias map.

Hope that helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Thu May 26 20:18:34 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Thu, 26 May 2011 18:18:34 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306433914.28.0.377859492763.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

Ashley, can you elaborate on wherein the ambiguity lies? Which combination of year, ISO week number and ISO weekday would lead to ambiguity?

Regarding documentation, the %G, %V and %u directives are listed in IEEE Std 1003.1, 2004 Edition for strftime(): http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html

For some reason, these directives are not mentioned in the related strptime(): http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 20:19:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 May 2011 18:19:32 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In response to a discussion of a patch removing 'useless' post-increments, (which issue has apparently come up before)
Guido posted
"> Sorry to butt in here, but I agree with Eric that it was better
> before. There is a common idiom, *pointer++ =<something>, and
> whenever you see that you know that you are appending something to an
> output buffer. Perhaps the most important idea here is that this
> maintains the *invariant* "pointer points just after the last thing in
> the buffer". Always maintaining the invariant is better than trying to
> micro-optimize things so as to avoid updating dead values. The
> compiler is better at that."

A condensed version of the above added to PEP 7 would help new developers see the usage as local idiom rather than style bug.

----------
assignee: docs at python
components: Documentation
messages: 136991
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: PEP 7, C style: add ++ policy and explanation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12188>
_______________________________________

From report at bugs.python.org  Thu May 26 20:28:25 2011
From: report at bugs.python.org (Feth AREZKI)
Date: Thu, 26 May 2011 18:28:25 +0000
Subject: [issue12189] Python 2.6.6 fails to compile a source whereas pycompile
	1.0 succeeds
In-Reply-To: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>
Message-ID: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>


New submission from Feth AREZKI <feth at tuttu.info>:

At least on Linux debian sid, it seems that Python 2.6.6 compile builtin does not like the empty line with only '\r\n' in it.

The following doctest story runs with the attached CRLF'ed file:
"""
>>> fd = open('test_win32.py', 'r')
>>> compile(fd.read(), 'test_win32.py', 'exec')
Traceback (most recent call last):
  File "/usr/lib/python2.6/doctest.py", line 1253, in __run
     compileflags, 1) in test.globs
  File "<doctest testcase_a[1]>", line 1, in <module>
     compile(fd.read(), 'test_win32.py', 'exec')
  File "test_win32.py", line 3
        ^
SyntaxError: invalid syntax
"""

With Python 2.7, everything seems fine.

----------
components: Interpreter Core
files: test_win32.py
messages: 136992
nosy: feth
priority: normal
severity: normal
status: open
title: Python 2.6.6 fails to compile a source whereas pycompile 1.0 succeeds
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file22130/test_win32.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12189>
_______________________________________

From report at bugs.python.org  Thu May 26 20:50:35 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 26 May 2011 18:50:35 +0000
Subject: [issue12189] Python 2.6.6 fails to compile a source whereas pycompile
	1.0 succeeds
In-Reply-To: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>
Message-ID: <1306435835.09.0.619223429955.issue12189@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem is probably near this code in Lib/doctest.py (in _load_testfile)::

        # get_data() opens files as 'rb', so one must do the equivalent
        # conversion as universal newlines would do.
        return file_contents.replace(os.linesep, '\n'), filename

probably something like this would be better::

    file_contents.replace('\r\n', '\n').replace('\r', '\n')

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12189>
_______________________________________

From report at bugs.python.org  Thu May 26 21:12:37 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 26 May 2011 19:12:37 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <4DDE948A.7020208@egenix.com>
Message-ID: <BANLkTino5pA20h88N1iJxF8z=X_s4NgdoA@mail.gmail.com>


Michele Orr? <maker.py at gmail.com> added the comment:

+1

What do you think? Ezio, David?

----------
title: The email package should defer to the codecs module for	all aliases -> The email package should defer to the codecs module for all aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Thu May 26 21:16:43 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Thu, 26 May 2011 19:16:43 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306437403.08.0.712043699419.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

The example that triggered the issue in testing was January 1, 1905. The ISO date for this day is 1904 52 7. This is reported correctly if you use datetime.isocalendar() or datetime.strftime('%G'), but you get 1905 if you use datetime.strftime('%Y'). When it's read back in it causes the test to fail because ISO '1904 52 7' is different from ISO '1905 52 7'.

Likewise if you consider a year starting on a Tuesday, Wednesday, or Thursday, there will be several days at the end of the previous year that will have an ISO year ahead of their Gregorian representation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 21:21:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2011 19:21:30 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306437690.58.0.560040074084.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, my thought was to avoid having multiple charset alias lists in the stdlib, and reusing the one in codecs, which is larger than the one in email, seemed to make sense.  This came up because a bug was reported where email (silently) failed to encode a string because the charset alias, while present in codecs, wasn't present in the email ALIASES table.

I suppose that as an alternative I could add full support for the IANA aliases list to email.  Email is the most likely place to run in to variant charset aliases anyway.

If that's the way we go, then this issue should be changed over to covering just updating codecs with the missing aliases, and a new issue opened for adding full IANA alias support to email.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Thu May 26 21:30:13 2011
From: report at bugs.python.org (Mike Solomon)
Date: Thu, 26 May 2011 19:30:13 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>


New submission from Mike Solomon <msolo at gmail.com>:

I work on a large app and we noticed that a surprising portion of our heap was filenames embedded the the bytecode.

This one-line patch to intern filenames reduces our on-disk size about ~15% and brings down our heap and in-memory object count by a similar percentage.

----------
components: Interpreter Core
files: codegen.patch
keywords: patch
messages: 136997
nosy: Mike.Solomon
priority: normal
severity: normal
status: open
title: intern filenames in bytecode
type: performance
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file22131/codegen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Thu May 26 21:35:36 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 26 May 2011 19:35:36 +0000
Subject: [issue8898] The email package should defer to the codecs module for
	all aliases
In-Reply-To: <1306437690.58.0.560040074084.issue8898@psf.upfronthosting.co.za>
Message-ID: <BANLkTim6CJUUF1CLcD=eS2DZP=vROPdy=w@mail.gmail.com>


Michele Orr? <maker.py at gmail.com> added the comment:

In that case, I could still take care of it; it would be really easy to do.

So, it's up to you to tell me what is the best design choice. (:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Thu May 26 21:37:54 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 26 May 2011 19:37:54 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1306438674.55.0.601250937087.issue12188@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12188>
_______________________________________

From report at bugs.python.org  Thu May 26 21:40:27 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 26 May 2011 19:40:27 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306438827.82.0.358432575328.issue12190@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/issue12190>
_______________________________________

From report at bugs.python.org  Thu May 26 21:44:12 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 May 2011 19:44:12 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1306437690.58.0.560040074084.issue8898@psf.upfronthosting.co.za>
Message-ID: <4DDEAD7E.7060500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> Well, my thought was to avoid having multiple charset alias lists in the stdlib, and reusing the one in codecs, which is larger than the one in email, seemed to make sense.  This came up because a bug was reported where email (silently) failed to encode a string because the charset alias, while present in codecs, wasn't present in the email ALIASES table.
> 
> I suppose that as an alternative I could add full support for the IANA aliases list to email.  Email is the most likely place to run in to variant charset aliases anyway.
> 
> If that's the way we go, then this issue should be changed over to covering just updating codecs with the missing aliases, and a new issue opened for adding full IANA alias support to email.

I think it would be useful to have a mapping from the Python
canoncial name (the one the encodings package uses) to the
"preferred MIME name" as referenced in the IANA list:

http://www.iana.org/assignments/character-sets

This mapping could also be added to the encodings package
together with a function that translates a given encoding
name to its canoncial Python name (codec_module_name())
and another one to translate it to the "preferred MIME name"
according to the above list (encoding_mime_name()).

Note that we don't support all the aliases mentioned in the IANA
list because many of the are outdated and some have proved to be
wrong (the aliased encodings are actually different in a few
places). There are also a few encodings in the list which we
don't support at all.

Since we only rarely get requests for supporting new aliases or
encodings, I think it's safe to say that the existing set
is fairly complete from a practical point of view.

----------
title: The email package should defer to the codecs module for all aliases -> The email package should defer to the codecs module for	all aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Thu May 26 21:47:42 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 May 2011 19:47:42 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306439262.91.0.407172448409.issue12190@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

How exactly does it bring down your disk space?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Thu May 26 21:50:19 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 26 May 2011 19:50:19 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1306439419.74.0.794567024277.issue3754@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

At least one is really would like to cross-compile.

worber, the config site has to look like (sample for linux i?86, i.e. intel 32 bit, as host platform)
=================================
ac_cv_little_endian_double=yes
ac_cv_broken_sem_getvalue=no
ac_cv_computed_gotos=yes
ac_cv_buggy_getaddrinfo=no
ac_cv_working_tzset=yes
#next line require fix typo in configure.in
ac_cv_pthread=yes
ac_cv_pthread_system_supported=yes
ac_cv_tanh_preserves_zero_sign=yes

ac_cv_have_long_long_format=yes
ac_cv_file__dev_ptmx=yes
ac_cv_file__dev_ptc=no
=================================

Also with following patch into configure.in
=======================================
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -1372,7 +1372,7 @@
 # so we need to run a program to see whether it really made the
 # function available.
 AC_MSG_CHECKING(whether $CC accepts -pthread)
-AC_CACHE_VAL(ac_cv_thread,
+AC_CACHE_VAL(ac_cv_pthread,
 [ac_save_cc="$CC"
 CC="$CC -pthread"
 AC_RUN_IFELSE([AC_LANG_SOURCE([[
=======================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu May 26 21:51:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 May 2011 19:51:34 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306439494.29.0.787501274396.issue12190@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo
type: performance -> resource usage
versions: +Python 3.3 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Thu May 26 22:00:10 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Thu, 26 May 2011 20:00:10 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306440010.38.0.980638874286.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

Oh, I see, you're talking about strftime(). You're correct that you would need %G to print the year to which the ISO week containing the specific date belongs. I see no ambiguity or need for %G in strptime().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu May 26 22:13:09 2011
From: report at bugs.python.org (Feth AREZKI)
Date: Thu, 26 May 2011 20:13:09 +0000
Subject: [issue12189] Python 2.6.6 fails to compile a source whereas pycompile
	1.0 and Python 2.7 succeed
In-Reply-To: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>
Message-ID: <1306440789.51.0.976655199789.issue12189@psf.upfronthosting.co.za>


Feth AREZKI <feth at tuttu.info> added the comment:

Amaury Forgeot d'Arc wrote:
>The problem is probably near this code in Lib/doctest.py (in _load_testfile)::

Hm, I discovered this without using doctest, and used it only to present the testcase. Are you sure that it relates to Lib/doctest (candid question, I never looked in that source before)?

----------
title: Python 2.6.6 fails to compile a source whereas pycompile 1.0 succeeds -> Python 2.6.6 fails to compile a source whereas pycompile 1.0 and Python 2.7 succeed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12189>
_______________________________________

From report at bugs.python.org  Thu May 26 22:14:10 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 26 May 2011 20:14:10 +0000
Subject: [issue12191] Shutil - add chown() in order 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: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up the discussion on http://mail.python.org/pipermail/python-dev/2011-May/111642.html here'a patch to introduce shutil.chown() along with doc, tests and a change in os doc to link to the new function (I also took the occasion to rewrap os.chown() doc text). As of now only the one-file function is implemented, let's see at a later time what's about for a recursive one.

The patch was prepared against default, but it probably makes sense to backport it to 2.7?

Any comment/suggestion is welcome!

----------
assignee: sandro.tosi
components: Library (Lib)
files: shutil_chown-default.patch
keywords: patch
messages: 137004
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Shutil - add chown() in order to allow to use user and group name (and not only uid/gid)
type: feature request
Added file: http://bugs.python.org/file22132/shutil_chown-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Thu May 26 22:14:19 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 26 May 2011 20:14:19 +0000
Subject: [issue12191] Shutil - add chown() in order 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: <1306440859.76.0.0529646465561.issue12191@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Thu May 26 22:24:41 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 26 May 2011 20:24:41 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306441481.35.0.530879357545.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Ok, so it's actually 0a1baa619171 that broke it, not sure how I came up with the other revision. In any case, it's too hairy to try and piece everything together across the numerous bug fixes, feature adds, and refactorings in this area in order to get back to a working state (plus you'll want to jump out the window if you try, believe me). I'm going to have a go at basically rewriting the os.stat Windows path tonight and tomorrow and see what that does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Thu May 26 22:30:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2011 20:30:52 +0000
Subject: [issue12189] Python 2.6.6 fails to compile a source whereas pycompile
	1.0 and Python 2.7 succeed
In-Reply-To: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>
Message-ID: <1306441852.41.0.733758806774.issue12189@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There are a number of issues with compile that have been fixed.  See #4628 and #1479099 for example.

Since you say it works with 2.7, and Python3 compile handles \r\n, and 2.6 is in security fix only mode, I'm closing this as out of date.  If you think there's still a problem in a maintained version of Python, please reopen.

----------
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/issue12189>
_______________________________________

From report at bugs.python.org  Thu May 26 22:35:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2011 20:35:35 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306442135.41.0.357393104995.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that since we get very few requests to add aliases our current tables are probably what we want.  So adding the MIME_preferred_name mapping *somewhere* is indeed what I would like to see happen.  It doesn't matter to me whether it is in the codecs module or the email module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Thu May 26 22:45:22 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 26 May 2011 20:45:22 +0000
Subject: [issue12191] Shutil - add chown() in order 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: <1306442722.37.0.392370539488.issue12191@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

As a new feature, it can't be added to 2.7.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Thu May 26 23:33:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 May 2011 21:33:11 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

BACKGROUND
One of most common recurring topics on python-list (perhaps monthly) is newbies tripping over a mutation method returning None when they expect the collection. Today's example: "Puzzled by list-appending behavior".
An excerpt from the responses: 

"On 5/26/2011 11:58 AM, MRAB wrote:
> On 26/05/2011 06:17, Chris Rebert wrote:

>> list.remove(), list.sort(), and list.extend() similarly return None
>> rather than the now-modified list.

> I'd just like to point out that it's a convention, not a rigid rule.
> Sometimes it's not followed, for example, dict.setdefault."

In Python 1, I believe it was true that all mutation methods of mutable builtin collections (ie, lists -- I do not think dicts had any and sets did not exist yet) returned None. With the introduction of list.pop, the return-None rule was 'broken', though the meme continues. However, the flip side of that rule, do-not-return-the-collection, continues to be true. And the return_None rule was not really broken, but broadened to "return None or an item from the collection". I believe this should be better documented than it is now.

PROPOSALS

1. State the general rule.

A. Tutorial: At the top of chapter 5, just after "This chapter describes some things you?ve learned about already in more detail, and adds some new things as well.", add something like

"For lists, sets, and dicts, methods that change the contents or order never return the instance. Instead, they return an item from the instance or, more commonly, None."

B. Library Manual: Near the top of 4. Built-in Types, after "The principal built-in types are numerics, sequences, mappings, classes, instances and exceptions.", add something like

"Some collection classes are mutable. The methods that add, subtract, or rearrange their members never return the collection instance itself but instead return an item from the instance or None."

Comment: This rule applies to special methods like __getitem__ and __setitem__. 'lis.append(item)' is equivalent to lis.__setitem__(len(lis):len(lis), item), so it should not be so surprising that it has the same return.

2. Document None returns explicitly.

They are currently documented implicitly, by absence.

A. Docstrings: Compare the relevant parts of the output from 'help(list.append)' and 'help(list.pop)'

   L.append(object) -- append object to end
   L.pop([index]) -> item -- remove and return item at index 

Add ' -> None' to specify return for .append.
   L.append(object) -> None -- append object to end

I expect experienced Python programmers may object that this puts too much emphasis on the unimportant null return, but it is important that Python programmers know about it and experience shows that many newbies *need* that emphasis.

B. Doc entries: Essentially same suggestion -- add 'Return None.' to appropriate entries in tutorial chapter 5. For library manual, possibly add footnote '(9) Returns None' to the method table in 4.6.4. Mutable Sequence Types. For sets and dicts, add 'and return None' to appropriate entries.

----------
assignee: docs at python
components: Documentation
messages: 137009
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Doc that collection mutation methods return item or None
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Thu May 26 23:41:45 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 26 May 2011 21:41:45 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306446105.14.0.329448388485.issue12190@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/issue12190>
_______________________________________

From report at bugs.python.org  Fri May 27 00:05:02 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 26 May 2011 22:05:02 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1306447502.49.0.239464008656.issue11995@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22133/python-2.7-issue_11995.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11995>
_______________________________________

From report at bugs.python.org  Fri May 27 00:05:26 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 26 May 2011 22:05:26 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1306447526.23.0.568970528327.issue11995@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file22134/python-3.2-issue_11995.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11995>
_______________________________________

From report at bugs.python.org  Fri May 27 00:05:47 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 26 May 2011 22:05:47 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1306447547.12.0.982909939424.issue11995@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Added file: http://bugs.python.org/file22135/python-3.3-issue_11995.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11995>
_______________________________________

From report at bugs.python.org  Fri May 27 00:06:02 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 26 May 2011 22:06:02 +0000
Subject: [issue11995] test_pydoc loads all Python modules
In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za>
Message-ID: <1306447562.37.0.834922094714.issue11995@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11995>
_______________________________________

From report at bugs.python.org  Fri May 27 00:17:39 2011
From: report at bugs.python.org (Mike Solomon)
Date: Thu, 26 May 2011 22:17:39 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306439262.91.0.407172448409.issue12190@psf.upfronthosting.co.za>
Message-ID: <BANLkTinpmaLQwWOfxa79s=bEDBsHzGs6wg@mail.gmail.com>


Mike Solomon <msolo at gmail.com> added the comment:

If you have a file with say a hundred functions, and each function contains
the full path of that file on disk, your pyc file will contain about
(100*(path_size+overhead)) bytes. In some cases, this is pretty
significant.

On Thu, May 26, 2011 at 12:47 PM, Benjamin Peterson
<report at bugs.python.org>wrote:

>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> How exactly does it bring down your disk space?
>
> ----------
> nosy: +benjamin.peterson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12190>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22136/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________
-------------- next part --------------
If you have a file with say a hundred functions, and each function contains the full path of that file on disk, your pyc file will contain about (100*(path_size+overhead)) bytes. In some cases, this is pretty significant.??<div>
<br><div><div class="gmail_quote">On Thu, May 26, 2011 at 12:47 PM, Benjamin Peterson <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>
Benjamin Peterson &lt;<a href="mailto:benjamin at python.org">benjamin at python.org</a>&gt; added the comment:<br>
<br>
How exactly does it bring down your disk space?<br>
<br>
----------<br>
nosy: +benjamin.peterson<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/issue12190" target="_blank">http://bugs.python.org/issue12190</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div></div>

From report at bugs.python.org  Fri May 27 00:20:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 26 May 2011 22:20:06 +0000
Subject: [issue12191] Shutil - add chown() in order 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: <1306448406.09.0.168086365192.issue12191@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I didn't test, but after skimming through the code I think that if an invalid user name/group name is provided, os.chown is passed None, which will fail with ValueError.
It would be better to raise an explicit error like "no such user" / "no such group".
That's something you could add to the tests.

Also, you could initialize _user to -1 instead of None, and replace
    if user is None:
        _user = -1
    else:
        [...]
with
    if user is not None:
        [...]

Same goes for _group.

----------
nosy: +charles-francois.natali

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Fri May 27 00:20:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 26 May 2011 22:20:13 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306448413.35.0.340716677621.issue12190@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22136/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Fri May 27 00:31:59 2011
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 26 May 2011 22:31:59 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1306449119.71.0.153420471502.issue12192@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/issue12192>
_______________________________________

From report at bugs.python.org  Fri May 27 00:38:05 2011
From: report at bugs.python.org (Ashley Anderson)
Date: Thu, 26 May 2011 22:38:05 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306449485.0.0.30853347649.issue12006@psf.upfronthosting.co.za>


Ashley Anderson <aganders3 at gmail.com> added the comment:

I disagree, I think %G is necessary in strptime(). Take Monday, December 31, 2001 as an example. The ISO date is 2002 01 1.

Now, given only the Gregorian year (2001) for this date, and the ISO week and weekday (01 1), there is an ambiguity with Monday, January 1, 2001, which has an ISO date of 2001 01 1. The ISO week/weekday combination of (01 1) occurs twice in the year 2001, and can only be differentiated by the corresponding ISO year.

We can, of course, debate on what the behavior in this case should be. The way I see it, we can:
1) Assume the year taken in by %Y is equivalent to the ISO year, which it often is. Assuming %Y is the ISO year IFF %V is used accomplishes the same result.
2) Default the year to some value, currently 1900 is used when %Y is absent. This is how it is handled now.
3) Report an error/exception that insufficient data was provided, and maybe mention %G should be used instead of %Y for this case.

I'm attaching a patch now that includes some minor changes, includes %G and adds some tests. I am also working on the documentation but it's not quite ready.

----------
Added file: http://bugs.python.org/file22137/12006_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Fri May 27 00:53:40 2011
From: report at bugs.python.org (Thorsten Kampe)
Date: Thu, 26 May 2011 22:53:40 +0000
Subject: [issue12193] Argparse does not work together with gettext and
	non-ASCII help text
In-Reply-To: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>
Message-ID: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>


New submission from Thorsten Kampe <thorsten at thorstenkampe.de>:

Error with argparse and UTF-8 non-ASCII help text on Linux (works on Windows and on Linux with optparse):

% LANG=de_De ./script.py --help
Traceback (most recent call last):
  File "./script.py", line 26, in <module>
    args = cmdlineparser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1678, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1916, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python2.7/argparse.py", line 1856, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python2.7/argparse.py", line 1784, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python2.7/argparse.py", line 993, in __call__
    parser.print_help()
  File "/usr/lib/python2.7/argparse.py", line 2303, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib/python2.7/argparse.py", line 2317, in _print_message
    file.write(message)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xdc' in position 91: ordinal not in range(128)

----------
components: Unicode
files: script.py
messages: 137013
nosy: thorsten
priority: normal
severity: normal
status: open
title: Argparse does not work together with gettext and non-ASCII help text
versions: Python 2.7
Added file: http://bugs.python.org/file22138/script.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12193>
_______________________________________

From report at bugs.python.org  Fri May 27 00:54:00 2011
From: report at bugs.python.org (Thorsten Kampe)
Date: Thu, 26 May 2011 22:54:00 +0000
Subject: [issue12193] Argparse does not work together with gettext and
	non-ASCII help text
In-Reply-To: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>
Message-ID: <1306450440.53.0.779212871188.issue12193@psf.upfronthosting.co.za>


Changes by Thorsten Kampe <thorsten at thorstenkampe.de>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12193>
_______________________________________

From report at bugs.python.org  Fri May 27 00:55:05 2011
From: report at bugs.python.org (Thorsten Kampe)
Date: Thu, 26 May 2011 22:55:05 +0000
Subject: [issue12193] Argparse does not work together with gettext and
	non-ASCII help text
In-Reply-To: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>
Message-ID: <1306450505.64.0.954222085946.issue12193@psf.upfronthosting.co.za>


Changes by Thorsten Kampe <thorsten at thorstenkampe.de>:


Added file: http://bugs.python.org/file22139/script.de.po

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12193>
_______________________________________

From report at bugs.python.org  Fri May 27 00:55:42 2011
From: report at bugs.python.org (Thorsten Kampe)
Date: Thu, 26 May 2011 22:55:42 +0000
Subject: [issue12193] Argparse does not work together with gettext and
	non-ASCII help text
In-Reply-To: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>
Message-ID: <1306450542.43.0.557400657736.issue12193@psf.upfronthosting.co.za>


Changes by Thorsten Kampe <thorsten at thorstenkampe.de>:


Added file: http://bugs.python.org/file22140/script.mo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12193>
_______________________________________

From report at bugs.python.org  Fri May 27 01:03:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 26 May 2011 23:03:49 +0000
Subject: [issue12193] Argparse does not work together with gettext and
	non-ASCII help text
In-Reply-To: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>
Message-ID: <1306451029.5.0.333415906857.issue12193@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +bethard
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12193>
_______________________________________

From report at bugs.python.org  Fri May 27 01:07:20 2011
From: report at bugs.python.org (Davi Post)
Date: Thu, 26 May 2011 23:07:20 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1306430232.75.0.323638534886.issue12042@psf.upfronthosting.co.za>
Message-ID: <BANLkTimkg1X8XP4Zd1WySUtjCOh-4UhGxg@mail.gmail.com>


Davi Post <post at pobox.com> added the comment:

Thanks Jordan. How about 2.7? Is that not an open branch?

--Davi

On Thu, May 26, 2011 at 12:17 PM, Jordan Stadler <report at bugs.python.org>wrote:

>
> Jordan Stadler <jordan.stadler at gmail.com> added the comment:
>
> Alright, patches are up for 3.1 and 3.2. I'm not sure if I can just make
> one for the 3.x's so I made both.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12042>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22141/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________
-------------- next part --------------
Thanks Jordan. How about 2.7? Is that not an open branch?<div><br></div><div>--Davi</div><div><br><br><div class="gmail_quote">On Thu, May 26, 2011 at 12:17 PM, Jordan Stadler <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>
Jordan Stadler &lt;<a href="mailto:jordan.stadler at gmail.com">jordan.stadler at gmail.com</a>&gt; added the comment:<br>
<br>
Alright, patches are up for 3.1 and 3.2. I&#39;m not sure if I can just make one for the 3.x&#39;s so I made both.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue12042" target="_blank">http://bugs.python.org/issue12042</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Fri May 27 01:37:09 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Thu, 26 May 2011 23:37:09 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306453029.21.0.050793709995.issue12042@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

To be honest, I'm getting a bit confused as to what is required. I thought the two most important patches would be 2.7 and 3.2, but we have 2.7, 3.1, 3.2, and 3.3 listed as versions affected.  

I posted the patch for 2.7 originally on May 14th.  I'm not sure if there is a problem with that patch I posted, but Eric didn't seem content with the versions.  At this time versions 3.1, 3.2, and 3.3 were added to the affected versions list.

Today I did the patches for 3.1 and 3.2, but I am unsure of how to provide one for 3.3 as is is not listed in mercurial for me (I'm probably doing something wrong, but I couldn't see it).

The change in the patch is so minor and I don't mind doing 3.3 if I can get my mercurial to update to 3.3.  If the change I made in the patches is insufficient please let me know, I have no problem making adjustments.  I'm still getting used to the patching process and how to properly contribute to the community.

TLDR: Basically, I'm a little confused as to whether or not the patches I provided are sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Fri May 27 01:43:40 2011
From: report at bugs.python.org (Greg Steuck)
Date: Thu, 26 May 2011 23:43:40 +0000
Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000
	files
In-Reply-To: <1196429217.61.0.167287216759.issue1526@psf.upfronthosting.co.za>
Message-ID: <1306453420.58.0.335165588584.issue1526@psf.upfronthosting.co.za>


Greg Steuck <gnezdo+pythonbugs at google.com> added the comment:

There may be a related issue that I still hit with 2.6.5.

% cat /tmp/a.py 
import zipfile
import os

z = zipfile.ZipFile('/tmp/a.zip', 'w')
open("/tmp/a", "w")
os.utime("/tmp/a", (0,0))
z.write("/tmp/a", "a")
% python -V
Python 2.6.5
% uname -mo
x86_64 GNU/Linux
% uname -mor
2.6.32-gg426-generic x86_64 GNU/Linux
% python /tmp/a.py
/usr/lib/python2.6/zipfile.py:1047: DeprecationWarning: struct integer overflow masking is deprecated
  self.fp.write(zinfo.FileHeader())
/usr/lib/python2.6/zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= number <= 65535
  self.fp.write(zinfo.FileHeader())
/usr/lib/python2.6/zipfile.py:1123: DeprecationWarning: struct integer overflow masking is deprecated
  self.close()
/usr/lib/python2.6/zipfile.py:1123: DeprecationWarning: 'H' format requires 0 <= number <= 65535
  self.close()

----------
nosy: +gnezdo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1526>
_______________________________________

From report at bugs.python.org  Fri May 27 01:54:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2011 23:54:03 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <E1QPkNL-00050V-Ln@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3555cf6f9c98 by Victor Stinner in branch 'default':
Issue #8796: codecs.open() calls the builtin open() function instead of using
http://hg.python.org/cpython/rev/3555cf6f9c98

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Fri May 27 02:02:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2011 00:02:59 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <E1QPkW2-00063m-46@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8cebbc6473d9 by Nadeem Vawda in branch 'default':
Issue #1625: BZ2File and bz2.decompress() now support multi-stream files.
http://hg.python.org/cpython/rev/8cebbc6473d9

New changeset 0be55601f948 by Nadeem Vawda in branch 'default':
Update bz2 docs following issue #1625.
http://hg.python.org/cpython/rev/0be55601f948

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Fri May 27 02:07:23 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 27 May 2011 00:07:23 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306454843.77.0.135101152369.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Committed. Once again, thanks for the patch!

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Fri May 27 03:57:25 2011
From: report at bugs.python.org (bemasc)
Date: Fri, 27 May 2011 01:57:25 +0000
Subject: [issue1144504] Add IEEE Float support to wave.py
Message-ID: <1306461445.12.0.0184877796659.issue1144504@psf.upfronthosting.co.za>


bemasc <bens at alum.mit.edu> added the comment:

I am the original author ... just ran into the same exact issue 6 years later, and google turned up this ticket.  This bug is still unfixed, and the patch is still correct.  The patch does not reject any valid WAV files.  Its worst sin is accepting and processing (correctly) some technically invalid files, which I would argue is actually desirable behavior.

----------
nosy: +bemasc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1144504>
_______________________________________

From report at bugs.python.org  Fri May 27 03:58:39 2011
From: report at bugs.python.org (Nicholas Marriott)
Date: Fri, 27 May 2011 01:58:39 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306461519.74.0.287135335703.issue12181@psf.upfronthosting.co.za>


Nicholas Marriott <nicholas.marriott at gmail.com> added the comment:

Hi

This is not an OpenBSD bug.

kqueue is not standardized. There is no reason for the ident member to be uintptr_t over u_int - either is valid, and so far I don't see any reason for us to try and change it.

----------
nosy: +nicm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 04:08:47 2011
From: report at bugs.python.org (Nicholas Marriott)
Date: Fri, 27 May 2011 02:08:47 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306462127.89.0.673047354301.issue12181@psf.upfronthosting.co.za>


Nicholas Marriott <nicholas.marriott at gmail.com> added the comment:

To follow up a little - I'm afraid that you should not depend on the internal layout of structures like this. We clearly document the kevent structure in kevent(2), and of course beyond that it is of course dependent on C padding rules.

It isn't a bug that we have different layout from FreeBSD.

If you can make a case for us to change the layout then maybe...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 04:45:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 May 2011 02:45:14 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306464314.87.0.935129966014.issue12042@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sometimes only one patch is needed, if it applies cleanly to both python2 and python3.  If it doesn't, then two patches are useful, one for python2.7 and one for python3.2.  (The last version of 3.1 is about to be released, so I don't think it likely that the fix will get in to that version.)  We will use hg merge to merge it into 3.3, which is simply the 'default' head in the repository.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Fri May 27 04:51:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 May 2011 02:51:40 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306464700.16.0.952585579687.issue12042@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Fri May 27 05:13:52 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 May 2011 03:13:52 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1306466032.18.0.161286692615.issue12188@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/issue12188>
_______________________________________

From report at bugs.python.org  Fri May 27 05:47:28 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 May 2011 03:47:28 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <BANLkTinpmaLQwWOfxa79s=bEDBsHzGs6wg@mail.gmail.com>
Message-ID: <BANLkTi=pPcYfxLVXRUFr9+RjhbJe1ig33w@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/5/26 Mike Solomon <report at bugs.python.org>:
>
> Mike Solomon <msolo at gmail.com> added the comment:
>
> If you have a file with say a hundred functions, and each function contains
> the full path of that file on disk, your pyc file will contain about
> (100*(path_size+overhead)) bytes. In some cases, this is pretty
> significant.

I see. The support for saving interned strings no longer exists in Py3
where this "feature" would have to be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Fri May 27 07:27:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 May 2011 05:27:17 +0000
Subject: [issue12191] Shutil - add chown() in order 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: <1306474037.34.0.443071191713.issue12191@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/issue12191>
_______________________________________

From report at bugs.python.org  Fri May 27 07:42:27 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 05:42:27 +0000
Subject: [issue12191] Shutil - add chown() in order 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: <1306474947.74.0.747307824086.issue12191@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/issue12191>
_______________________________________

From report at bugs.python.org  Fri May 27 07:58:23 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 05:58:23 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306475903.91.0.726506751713.issue12085@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I don't think you should remove the old patch, as it's a part of the discussion.

For the new patch, I'd explicitly state what can go wrong, e.g. add "(e.g. invalid parameters passed to __init__)" or something like that.

Otherwise, looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Fri May 27 08:05:18 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 27 May 2011 06:05:18 +0000
Subject: [issue1526] DeprecationWarning in zipfile.py while zipping 113000
	files
In-Reply-To: <1196429217.61.0.167287216759.issue1526@psf.upfronthosting.co.za>
Message-ID: <1306476318.49.0.928149799576.issue1526@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The ZIP file format is unable to store dates before 1980.  With version 3.2, your script even raises an exception.  Please file this in a different issue.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1526>
_______________________________________

From report at bugs.python.org  Fri May 27 08:31:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 May 2011 06:31:41 +0000
Subject: [issue12194] Fix LDFLAGS on Ubuntu 11.04+
In-Reply-To: <1306477901.19.0.823016401288.issue12194@psf.upfronthosting.co.za>
Message-ID: <1306477901.19.0.823016401288.issue12194@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

A complete build on Ubuntu currently requires fiddling with LDFLAGS before invoking configure (otherwise the build process fails to find the necessary pieces to build some modules):
http://www.technobits.net/articles/8919/christian-heimes-how-to-compile-python-on-ubuntu-1104/

It would be nice if this just worked from a fresh checkout when the appropriate dev packages have been installed.

----------
messages: 137027
nosy: barry, christian.heimes, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix LDFLAGS on Ubuntu 11.04+
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12194>
_______________________________________

From report at bugs.python.org  Fri May 27 09:07:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 07:07:53 +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: <1306480073.75.0.91611263994.issue12063@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

tokenize processes a line at a time, and noticing that an ending triple quote is missing would mean reading the whole file in the worst case. As tokenize seems to work in a generator-like fashion, it's probably not desired to cache all the input to be able to restart from some previous line.

So, I'd go with documenting the behavior.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12063>
_______________________________________

From report at bugs.python.org  Fri May 27 09:11:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 07:11:55 +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: <1306480315.98.0.189625133584.issue12063@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12063>
_______________________________________

From report at bugs.python.org  Fri May 27 09:13:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 May 2011 07:13:39 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1306480419.17.0.23615764736.issue12192@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 on the doc suggestions

-1 on any hope that casual users will have read or remembered them.  ISTM that a common theme among the post of people getting tripped-up by this is that they aren't doing more than a quick skim of the docs anyway.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Fri May 27 09:28:25 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Fri, 27 May 2011 07:28:25 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306481305.75.0.776825433014.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

I respectfully disagree. I take strptime('2002 01 1', '%Y %V %u') as mening "first day of first week in the year 2002"

There is only one date that corresponds to the first day of the first week of 2002, i.e. Dec. 31, 2001. If you specify the first day of the first week of 2001 instead, then that's another date (Jan. 1, 2001). The last and the first week in a year may span dates belonging to two years.  That's just the way it is.

Are you suggesting strptime('2002 01 1', '%Y %V %u') to mean "first day of first week of 2002, except if that would change the year, in which case it means ???"

If you want to strftime(strptime(date, fmt), fmt) and arrive at the original date then yes, you need %G (but only in strftime).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Fri May 27 09:39:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 27 May 2011 07:39:49 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <E1QPkNL-00050V-Ln@dinsdale.python.org>
Message-ID: <4DDF5537.7000408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Roundup Robot wrote:
> 
> Roundup Robot <devnull at devnull> added the comment:
> 
> New changeset 3555cf6f9c98 by Victor Stinner in branch 'default':
> Issue #8796: codecs.open() calls the builtin open() function instead of using
> http://hg.python.org/cpython/rev/3555cf6f9c98

Viktor, could you please back out this change again.

I am -1 on deprecating the StreamReader/Writer parts of the codec API
as I've mentioned numerous times and *don't* want to see these
deprecated in the code or the documentation.

I'm -0 on the change to codecs.open(). Have you checked whether the
returned objects are compatible ?

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-05-23: Released eGenix mx Base 3.2.0      http://python.egenix.com/
2011-05-25: Released mxODBC 3.1.1              http://python.egenix.com/
2011-06-20: EuroPython 2011, Florence, Italy               24 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Fri May 27 09:44:52 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 07:44:52 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306482292.79.0.803028017827.issue12181@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello Nicholas,

> kqueue is not standardized.

You're probably right, but depending on the version of your manpages, the definition changes:

http://www.openbsd.org/cgi-bin/man.cgi?query=kevent&apropos=0&sektion=0&manpath=OpenBSD+3.8&arch=i386&format=html defines

     struct kevent {
             uintptr_t ident;        /* identifier for this event */
             short     filter;       /* filter for event */
             u_short   flags;        /* action flags for kqueue */
             u_int     fflags;       /* filter flag value */
             intptr_t  data;         /* filter data value */
             void      *udata;       /* opaque user data identifier */
     };

Now, http://www.openbsd.org/cgi-bin/man.cgi?query=kevent&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html defines

     struct kevent {
             u_int   ident;          /* identifier for this event */
             short   filter;         /* filter for event */
             u_short flags;          /* action flags for kqueue */
             u_int   fflags;         /* filter flag value */
             int     data;           /* filter data value */
             void    *udata;         /* opaque user data identifier */
     };

The first page hit when searching for "openbsd struct kevent" refers to the first version...

> If you can make a case for us to change the layout then maybe... 

Well, I don't know if you can make such a backward-incompatible change, but for what it's worth, FreeBSD, NetBSD and OS-X all use uintptr_t.

But for now I'll gues we'll just add a specific case for OpenBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 09:58:52 2011
From: report at bugs.python.org (Nicholas Marriott)
Date: Fri, 27 May 2011 07:58:52 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306483132.61.0.41026308475.issue12181@psf.upfronthosting.co.za>


Nicholas Marriott <nicholas.marriott at gmail.com> added the comment:

Hi

The second one is correct - OpenBSD -current has this in event.h:

struct kevent {
        u_int           ident;          /* identifier for this event */
        short           filter;         /* filter for event */
        u_short         flags;
        u_int           fflags;
        int             data;
        void            *udata;         /* opaque user data identifier */
};

It's been like that since r1.1 so probably the 3.8 man page was wrong.

I don't know that backwards compatibility would be the main concern here, more what is the justification for changing. It does make sense to have ident wide enough to store a pointer so it would be better as a long, but making filter and flags into uint32_t seems unnecessary and I think udata is fine as a void*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 10:05:07 2011
From: report at bugs.python.org (Nicholas Marriott)
Date: Fri, 27 May 2011 08:05:07 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306483507.24.0.975618949177.issue12181@psf.upfronthosting.co.za>


Nicholas Marriott <nicholas.marriott at gmail.com> added the comment:

Not that I'm unsympathetic but this is really only a concern if you depend on the internal structure layout and I think if you do that, you need to take account of differences between platforms. We don't guarantee we aren't going to change the struct between versions and I doubt FreeBSD or NetBSD or OS X would make that guarantee either :-).

I'll see if we can change it but no promises and even if we do it'll be for later versions of OpenBSD anyway...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 10:18:15 2011
From: report at bugs.python.org (Thorsten Kampe)
Date: Fri, 27 May 2011 08:18:15 +0000
Subject: [issue12193] Argparse does not work together with gettext and
	non-ASCII help text
In-Reply-To: <1306450420.84.0.782316559531.issue12193@psf.upfronthosting.co.za>
Message-ID: <1306484295.02.0.699587046332.issue12193@psf.upfronthosting.co.za>


Thorsten Kampe <thorsten at thorstenkampe.de> added the comment:

"LANG=de_De" - should've been "LANG=de_DE". Sorry for wasting someone's time. I shouldn't write bug reports in the middle of the night.

Sorry and thanks, Thorsten

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12193>
_______________________________________

From report at bugs.python.org  Fri May 27 10:22:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 08:22:35 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306484555.95.0.598321120878.issue12181@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Concerning the differences between platforms, as noted, FreeBSD, NetBSD and OS-X are all consistent and I don't think it'll change tomorrow, so for now it's not a problem. Arbitrarily changing such structures definition - event though they're not standardized - is certainly not user-friendly, people will start complaining if their code breaks between two versions.

Nicholas, could you work on a patch so that kevent works on OpenBSD 64-bit? The relevant code is in Modules/selectmodule.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 10:27:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2011 08:27:09 +0000
Subject: [issue12189] Python 2.6.6 fails to compile a source whereas pycompile
	1.0 and Python 2.7 succeed
In-Reply-To: <1306434505.76.0.454452531251.issue12189@psf.upfronthosting.co.za>
Message-ID: <1306484829.81.0.284642250396.issue12189@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The bug is specific to compile(), the import machinery supports Windows newlines on Linux for example.

marge$ python2.6
Type "help", "copyright", "credits" or "license" for more information.
>>> code=open("win.py", "rb").read()
>>> exec compile(code, "win.py", "exec")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "win.py", line 1
    print("line 1")
                   ^
SyntaxError: invalid syntax

>>> import imp
>>> win=imp.load_source("win.py")
>>> win=imp.load_source("win.py", "win.py")
line 1
line 2
>>> win
<module 'win.py' from 'win.py'>

>>> import win
line 1
line 2

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12189>
_______________________________________

From report at bugs.python.org  Fri May 27 10:43:42 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Fri, 27 May 2011 08:43:42 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1306485822.75.0.804345525702.issue12006@psf.upfronthosting.co.za>


Erik Cederstrand <ec at 1calendar.dk> added the comment:

Reading you comment again, I see the ambiguity now, if %Y is interpreted as "The resulting date MUST be in 2001".

I think the safest way would be to implement %G and fail if %Y is used in combination with %V. Maybe even fail if %V and %u aren't used in combination (since using %w could mean either the Sunday in the end of ISO week X or the Sunday preceeding ISO week X).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Fri May 27 10:51:04 2011
From: report at bugs.python.org (Nicholas Marriott)
Date: Fri, 27 May 2011 08:51:04 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1306486264.1.0.890727666693.issue12181@psf.upfronthosting.co.za>


Nicholas Marriott <nicholas.marriott at gmail.com> added the comment:

Well "they do it that way" is not a justification that necessarily works for OpenBSD :-).

I'll see if I can come up with a diff to fix this in Python. Not this weekend though, maybe next week. Unless Remi do you want to have a go?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 10:52:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2011 08:52:15 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306482292.79.0.803028017827.issue12181@psf.upfronthosting.co.za>
Message-ID: <201105271052.09225.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If there are only two versions of the structure on all operating systems, we 
can add a check in configure (e.g. test the size of the ident attribute, =int 
or >=void*?) to define a macro (e.g. HAVE_OPENBSD_KEVENT_STRUCT). You might be 
able to change the type of the fields in the Python structure at run time (in 
select module init), but I prefer to do it at compile time! Or you can add 
*checks* at runtime (at select init) on the size of the fields.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Fri May 27 10:52:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 27 May 2011 08:52:53 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1306486373.26.0.5159698283.issue12192@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I find this wording a little confusing: "For lists, sets, and dicts, methods that change the contents or order never return the instance. Instead, they return an item from the instance or, more commonly, None.".
I would suggest to drop the second part because we don't care about those methods now and because some of them return None too, and simply use "Methods that mutate the object never return the instance.", possibly adding something like "to remind you that no new objects have been created.".
The same wording can be used in both the Tutorial and the Library Manual (if readers happen to read it twice, it's even more likely that they will remember it).

FWIW the glossary has entries for "mutable" and "immutable", adding a note about this convention in the "mutable" entry might be a good idea too.

Adding the '-> None' in the docstring is fine too, I'm not sure about the footnote.

Terry, do you want to work on a patch?

----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Fri May 27 12:37:30 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 10:37:30 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1306492650.32.0.885094158264.issue12021@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Added a patch. It was only a matter of making the size parameter optional.

----------
keywords: +patch
nosy: +petri.lehtinen
Added file: http://bugs.python.org/file22142/mmap_read_all.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Fri May 27 12:54:22 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 10:54:22 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1306493662.88.0.782230011925.issue12021@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Updated the patch to also update the documentation of mmap.read().

----------
Added file: http://bugs.python.org/file22143/mmap_read_all_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Fri May 27 12:59:12 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 27 May 2011 10:59:12 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306493952.1.0.114928144142.issue11969@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Diff attached, is it good? I'm not very experienced with diffs, I usually work with pull requests.

----------
keywords: +patch
Added file: http://bugs.python.org/file22144/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 13:21:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 11:21:09 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306495269.04.0.478084925086.issue11969@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Your patch is good in this case, as the person who applies the patch knows which file is affected.

In the future, use diff -u original_file modified_file to get a unified diff. It's the "de facto" format for patches.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 13:28:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 27 May 2011 11:28:08 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306495688.92.0.911727596169.issue11969@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Actually, I only commented on the patch format and not on the actual contents of the patch, sorry :)

Your test method missed the self parameter, and the test case needed to be added to the testcases_other list for the test to be actually run. I attached a corrected patch.

And, now that I tested it, the test runs correctly on Linux, so maybe this is a Windows specific issue?

----------
Added file: http://bugs.python.org/file22145/patch_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 13:44:36 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 27 May 2011 11:44:36 +0000
Subject: [issue12191] Shutil - add chown() in order 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: <1306496676.45.0.017825852916.issue12191@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/issue12191>
_______________________________________

From report at bugs.python.org  Fri May 27 14:22:13 2011
From: report at bugs.python.org (JJeffries)
Date: Fri, 27 May 2011 12:22:13 +0000
Subject: [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>


New submission from JJeffries <jamesjeffries1 at gmail.com>:

There are very few pages relating to annotations in the documentation. Making it very unclear how they work and what they could be used for other than the original PEP.

----------
assignee: docs at python
components: Documentation
messages: 137047
nosy: JJeffries, docs at python
priority: normal
severity: normal
status: open
title: Little documentation of annotations
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12195>
_______________________________________

From report at bugs.python.org  Fri May 27 14:47:47 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 27 May 2011 12:47:47 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306500467.38.0.751022412473.issue8898@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Any idea about how to unittest mime.aliases?

Also, since I've just created a new file, are there some buracratic issues? I mean, do I have to add something at the top of the file?
(I'm just signing the Contributor Agreement)

----------
Added file: http://bugs.python.org/file22146/issue8898_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 15:12:17 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 27 May 2011 13:12:17 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1306500467.38.0.751022412473.issue8898@psf.upfronthosting.co.za>
Message-ID: <4DDFA323.2020708@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Michele Orr? wrote:
> 
> Michele Orr? <maker.py at gmail.com> added the comment:
> 
> Any idea about how to unittest mime.aliases?

Test the APIs you probably created for accessing it.

> Also, since I've just created a new file, are there some buracratic issues? I mean, do I have to add something at the top of the file?
> (I'm just signing the Contributor Agreement)

You just need to put the usual copyright line at the top of
the file, together with the sentence from the agreement.

Apart from that, you also need to make sure that the other build
setups include the new file (PCbuild, Makefile.pre.in, etc.). If you
don't know how to do this, you can ask someone else to take
care of this, since it usually requires domain knowledge (e.g.
to add the file to the Windows builds).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 15:48:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 May 2011 13:48:37 +0000
Subject: [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1306504117.35.0.488247454457.issue12195@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We could beef this up a little bit, but it was intentional that we leave it completely open on how to use it.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12195>
_______________________________________

From report at bugs.python.org  Fri May 27 15:59:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 May 2011 13:59:13 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306504753.98.0.599669656753.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your new file isn't in the patch.  I'm imagining it is a table and a couple methods, so I think perhaps putting it either in charset or in utils would be better than creating a new file.

As for testing it, what I'd love to see is a test that downloads the current IANA table (there are routines in test.support for doing this in a way that respects the test suite's 'resources' settings), pulls out the preferred MIME aliases, and makes sure that all of them are mapped to some canonical Python codec.  Then you can invert that and make sure all of the results returned by that test map back to the correct MIME alias.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 16:07:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2011 14:07:47 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <E1QPxha-0003W2-AQ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 27359a4e0f8c by Benjamin Peterson in branch 'default':
try to use the same str object for all code filenames when compiling or unmarshalling (#12190)
http://hg.python.org/cpython/rev/27359a4e0f8c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Fri May 27 16:10:04 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 May 2011 14:10:04 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306505404.19.0.825669009534.issue12190@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

As you can see, I've implemented a similar solution in 3.3. It should have the same memory savings but not disk space saving. (This would require reintroducing the marshal feature for interned strings.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Fri May 27 16:11:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 14:11:01 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

pipe2() makes it possible to create a pipe O_CLOEXEC or O_NONBLOCK atomically, which can be quite useful, especially in multi-threaded code. It would be nice to expose it in the os module.
Patch attached.

----------
components: Library (Lib)
files: posix_pipe2.diff
keywords: needs review, patch
messages: 137054
nosy: charles-francois.natali, haypo, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: add pipe2() to the os module
type: feature request
versions: Python 3.4
Added file: http://bugs.python.org/file22147/posix_pipe2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 16:20:28 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 May 2011 14:20:28 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1306506028.62.0.339700642471.issue11610@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

FWIW, if you still want to advance this, you could bring it up on Python-dev. I still feel uncomfortable with the API but could be convinced with others thought it was the best solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri May 27 16:24:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 May 2011 14:24:06 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306506246.69.0.618156765056.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Prompted on IRC, I see I missed the file because it was so short.

This still isn't what I'm looking for.  We are assuming that email is going to use the codec eventually so that it is not a bad thing to have charset pre-populate the codec cache.  So what I'm looking for is:

    try:
        python_name = codecs.lookup(input_charset).name
        mime_name = ALIASES.get(python_name, input_charset)
    except LookupError:
        mime_name = input_charset

MAL's idea was to implement the ALIASES step via a two-way mapping in the encodings module (python-canonical-name <=> MIME-preferred-name).  That would be fine, too, but the email.charset logic should look like the above however the table is implemented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 16:34:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2011 14:34:37 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306506877.39.0.678592851218.issue12196@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+        self.assertRaises(TypeError, os.pipe2, (0, 0))

Do you want to call the function with two arguments or one tuple with 2 items? You may test both :-)

+        # try a write big enough to fill-up the pipe (64K on most kernels): this
+        # should perform a partial write, not block
+        os.write(w, b'x' * 100000)

This constant should be moved to test.support. BaseTestCase.test_communicate_pipe_buf() on subprocess uses:

        x, y = os.pipe()
        if mswindows:
            pipe_buf = 512
        else:
            pipe_buf = os.fpathconf(x, "PC_PIPE_BUF")

SignalsTest.check_interrupted_write() of test_io uses:

            # Fill the pipe enough that the write will be blocking.
            # It will be interrupted by the timer armed above.  Since the
            # other thread has read one byte, the low-level write will
            # return with a successful (partial) result rather than an EINTR.
            # The buffered IO layer must check for pending signal
            # handlers, which in this case will invoke alarm_interrupt().
            self.assertRaises(ZeroDivisionError,
                              wio.write, item * (1024 * 1024))

Instead of a constant, it may be function taking a pipe end as argument and returning the size of its buffer. Something like:

def pipe_buffer_size(fd):
    if hasattr(os, 'fpathconf'): # better than sys.platform == "win32"?
        pipe_buf = 512
    else:
        pipe_buf = os.fpathconf(fd, "PC_PIPE_BUF")

+        self.assertTrue((time.time() - start) < 1.0, "Test took too long for O_NONBLOCK.")

Hum, I'm not sure that it's revelant to test the time: if the call blocks, it will block forever. If the system is busy, the read+write may takes longer than 1 second.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 16:50:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2011 14:50:51 +0000
Subject: [issue8796] Deprecate codecs.open()
In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za>
Message-ID: <E1QPyNG-0007Ck-66@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 4d2ddd86b531 by Victor Stinner in branch 'default':
Revert my commit 3555cf6f9c98: "Issue #8796: codecs.open() calls the builtin
http://hg.python.org/cpython/rev/4d2ddd86b531

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8796>
_______________________________________

From report at bugs.python.org  Fri May 27 16:51:50 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 27 May 2011 14:51:50 +0000
Subject: [issue12194] Fix LDFLAGS on Ubuntu 11.04+
In-Reply-To: <1306477901.19.0.823016401288.issue12194@psf.upfronthosting.co.za>
Message-ID: <1306507910.81.0.919263177523.issue12194@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Building Python on multiarch Debian and Ubuntu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12194>
_______________________________________

From report at bugs.python.org  Fri May 27 17:21:03 2011
From: report at bugs.python.org (Josh Triplett)
Date: Fri, 27 May 2011 15:21:03 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306509663.74.0.0500295291708.issue12082@psf.upfronthosting.co.za>


Josh Triplett <josh at joshtriplett.org> added the comment:

GRUB's filesystem drivers don't support reading mtime.  And no, no form of stat() function exists, f or otherwise.

On a related note, without HAVE_STAT, import.c can't import package modules at all, since it uses stat to check in advance for a directory.  In the spirit of Python's usual "try it and see if it works" approach, why not just try opening foo/__init__.py, and if that doesn't work try opening foo.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Fri May 27 17:23:01 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 27 May 2011 15:23:01 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306509781.72.0.134775443672.issue11969@psf.upfronthosting.co.za>


Changes by Ram Rachum <cool-rr at cool-rr.com>:


Removed file: http://bugs.python.org/file22144/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 17:23:10 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 27 May 2011 15:23:10 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306509790.22.0.256892121042.issue11969@psf.upfronthosting.co.za>


Changes by Ram Rachum <cool-rr at cool-rr.com>:


Removed file: http://bugs.python.org/file22027/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 17:24:13 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 May 2011 15:24:13 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306509853.0.0.512554438718.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The second line in that try: block should have been:

  mime_name = ALIASES.get(python_name, python_name)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 17:26:01 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 27 May 2011 15:26:01 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306509961.13.0.300936016702.issue11969@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Thanks for the `-u` tip and the correction to the code, Petri. I removed my previous files since yours is the definite one. And yeah, it's a Windows issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 17:45:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 15:45:06 +0000
Subject: =?utf-8?q?=5Bissue10449=5D_=E2=80=9Cos=2Eenviron_was_modified_by_test=5Fh?=
	=?utf-8?q?ttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1306511106.42.0.0832831220911.issue10449@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Stealing two lines from 3.2 fixes this.  See attached patch.

----------
keywords: +patch
stage: needs patch -> commit review
Added file: http://bugs.python.org/file22148/fix-environ-test_httpservers-3.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10449>
_______________________________________

From report at bugs.python.org  Fri May 27 17:45:33 2011
From: report at bugs.python.org (Jordan Stadler)
Date: Fri, 27 May 2011 15:45:33 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306511133.58.0.612544483667.issue12042@psf.upfronthosting.co.za>


Jordan Stadler <jordan.stadler at gmail.com> added the comment:

Alright, thanks for the clarification, that's pretty much how I thought it worked. Patches supplied should be good then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Fri May 27 17:46:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 15:46:27 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1306511187.63.0.958778642343.issue8887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Turns out the fix is very simple.  Please review.

----------
keywords: +needs review, patch
nosy: +ysj.ray
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.3
Added file: http://bugs.python.org/file22149/fix-pydoc-str.translate-3.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri May 27 17:47:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 15:47:36 +0000
Subject: [issue12019] Dead or buggy code in importlib.test.__main__
In-Reply-To: <1304698107.84.0.876175210451.issue12019@psf.upfronthosting.co.za>
Message-ID: <1306511256.88.0.24819796174.issue12019@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I read again the part of the PEP about __file__ and decided the code is a dead branch, so I removed it.

----------
keywords: +needs review, patch
stage:  -> commit review
Added file: http://bugs.python.org/file22150/dead-code-importlib-test-main-3.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12019>
_______________________________________

From report at bugs.python.org  Fri May 27 17:48:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 May 2011 15:48:08 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306511288.6.0.554903477627.issue11969@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Jesse, I do not understand your comment, including 'REPL'

----------
components: +Windows
versions: +Python 3.2 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 17:51:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 15:51:51 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306511511.76.0.533330116929.issue12196@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Do you want to call the function with two arguments or one tuple with 2 items? You may test both :-)

The former. Fixed.

> Hum, I'm not sure that it's revelant to test the time

I didn't like it either, I just reused what's done in test_socket. Fixed.

> BaseTestCase.test_communicate_pipe_buf() on subprocess uses

Yeah, except that it doesn't work, POSIX's PIPE_BUF is the guaranteed limit for the write to be atomic, not the buffer size (furthermore the libc doesn't have any way to know the pipe's buffer size or max atomic write, it's just a defined constant).

$ cat /tmp/test_pipe.py 
import os

r, w = os.pipe()
max = os.fpathconf(w, 'PC_PIPE_BUF')
print(max)
os.write(w, 2 * max * b'x')
print('ok')

$ ./python /tmp/test_pipe.py 
4096
ok

> This constant should be moved to test.support.

Patch attached.
It uses a constant of 1MB, even on Windows. I hope it won't break there, you never know with Windows...

----------
Added file: http://bugs.python.org/file22151/support_pipe_max.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 17:51:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 15:51:58 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306511518.12.0.554223120366.issue11906@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know if we should go out of our way to support running tests in interactive mode.  Running them from regrtest is the recommended way.

----------
title: Test_argparse failure but only in interactive mode -> test_argparse failure in interactive mode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri May 27 17:52:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 15:52:06 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306511526.39.0.0803689288189.issue12196@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22147/posix_pipe2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 17:52:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 15:52:43 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306511563.4.0.761368675145.issue12196@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22152/posix_pipe2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 17:53:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 15:53:15 +0000
Subject: [issue11948] Tutorial/Modules - small fix to better clarify the
	modules search path
In-Reply-To: <1304011111.24.0.834772686878.issue11948@psf.upfronthosting.co.za>
Message-ID: <1306511595.74.0.273623459078.issue11948@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think I?d better leave this one to Terry or Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11948>
_______________________________________

From report at bugs.python.org  Fri May 27 17:59:56 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 27 May 2011 15:59:56 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306511996.88.0.0976656710086.issue8898@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22153/issue8898_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 18:02:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2011 16:02:25 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306512145.22.0.117115529403.issue12196@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+# A constant likely larger than the underlying OS pipe buffer size.
+# Windows limit seems to be around 512B, and most Unix kernels have a 64K pipe
+# buffer size: take 1MB to be sure.
+PIPE_MAX_SIZE = 1024 * 1024

Hum, I am not sure that the comment is correct. If I understood correctly the usage of this constant: write PIPE_MAX_SIZE into a blocking pipe must block because PIPE_MAX_SIZE is greater than the size of the pipe buffer. I don't know what happen if you write PIPE_MAX_SIZE into a nonblocking pipe: the beginning of the buffer is written and write() returns something lesser than PIPE_MAX_SIZE?

You may specify that if you should greater or equal to os.fpathconf(fd, "PC_PIPE_BUF").

-----------

                               'sys.stderr.write("xyz"*%d);'
-                              'sys.stdout.write(sys.stdin.read())' % pipe_buf],
+                              'sys.stdout.write(sys.stdin.read())' %
+                              support.PIPE_MAX_SIZE],

and

+        string_to_write = b"abc" * support.PIPE_MAX_SIZE

Here you use PIPE_MAX_SIZE*3, not PIPE_MAX_SIZE :-) You can use b'abc' * (support.PIPE_MAX_SIZE // 3), or b'a' * support.PIPE_MAX_SIZE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 18:05:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2011 16:05:20 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1306512320.89.0.122181363068.issue8407@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oooooh, sigwait() doesn't accept a timeout! I would be nice to have also sigwaitinfo().. and maybe also its friend, sigwaitinfo() (if we implement the former, it's trivial to implement the latter). Python 3.3 adds optional timeout to subprocess.wait(), subprocess.communicate(), threading.Lock.acquire(), etc. And I love timeout! It was really useful to implement the thread of faulthandler.dump_tracebacks_later().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Fri May 27 18:08:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 16:08:51 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306512531.02.0.870899003016.issue8898@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> email (silently) failed to encode a string

Is this silent error another bug to fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 18:12:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 27 May 2011 16:12:11 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1306512731.32.0.139009339333.issue8887@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch looks good.  A nit-pick:

+        if len(parts) > 0:

Since *parts* is a list, the above can be replaced with simply "if parts:".

Also, it seems to me that the new code may produce an AttributeError when given invalid name, but locate() function is supposed to return None instead.

I wouder if it would be possible to reuse the try/except logic ing the "if module" clause and simply do something like

    if module:
        object = module
    else:
        object = builtins
    for part in parts[n:]:
        try:
            object = getattr(object, part)
        except AttributeError:
            return None
    return object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri May 27 18:15:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 16:15:19 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306512919.89.0.446806539794.issue1625@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made a few comments and asked two questions on the review page.  (I should have said so here.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Fri May 27 18:15:41 2011
From: report at bugs.python.org (Darren Dale)
Date: Fri, 27 May 2011 16:15:41 +0000
Subject: [issue11610] Improving property to accept abstract methods
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1306512941.48.0.057035808991.issue11610@psf.upfronthosting.co.za>


Darren Dale <dsdale24 at gmail.com> added the comment:

Thank you for the suggestion. I will follow up at python-dev, but it will probably be a few weeks before I have time to do a proper job of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11610>
_______________________________________

From report at bugs.python.org  Fri May 27 18:22:03 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 27 May 2011 16:22:03 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306513323.61.0.0193093165987.issue11906@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Unless Terry wants to contribute a fix I suggest closing this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri May 27 18:23:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 16:23:01 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1306513381.59.0.0318152006474.issue8887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Since *parts* is a list, the above can be replaced with simply "if parts:"

Heh, I always use implied truth values and one disagreed with Tarek about this, but here if felt more natural to spell out my mind with an explicit > 0 comparison :)

> Also, it seems to me that the new code may produce an AttributeError
> when given invalid name

I didn?t see that, I forgot to test invalid names, since test_pydoc already has some checks.  I?ll add tests and see if I can reproduce what you?re hinting at (it would be helpful if you could give examples of invalid names: full dotted names, method names, class names?).

> I wouder if it would be possible to reuse the try/except logic ing
> the "if module" clause

Sure, as long as the tests pass I have no preference about the implementation.  BTW, what?s your opinion on the test I added?  I use render_doc to test name resolving, do you think I should also test the command-line pydoc in a subprocess or is it okay to have white-box knowledge here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri May 27 18:26:21 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 27 May 2011 16:26:21 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1306513381.59.0.0318152006474.issue8887@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=crxr7wUPpO9UcG_x6VM9mEOXhVA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, May 27, 2011 at 12:23 PM, ?ric Araujo <report at bugs.python.org> wrote:
> .. I?ll add tests and see if I can reproduce what you?re hinting at (it would be helpful
> if you could give examples of invalid names: full dotted names, method names, class names?).

I did not try to apply your patch yet, but what I had in mind was
misspelled names like "str.transkate".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Fri May 27 18:27:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 16:27:50 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306513670.07.0.108880361962.issue12196@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22152/posix_pipe2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 18:28:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 16:28:24 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306513704.7.0.602413232757.issue12196@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file22154/posix_pipe2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 18:31:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 May 2011 16:31:07 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306513867.33.0.987304287806.issue11969@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

REPL is the Python interactive prompt in this case (REPL is Read Eval Print Loop).  So Jesse is saying that using multiprocessing from the REPL (at least on Windows) isn't supported.  This is because on Windows multiprocessing needs to re-import the main program in order to start the function in a worker process.  When using the REPL, there is no main program from which to import the function.

The test case failing on windows may or may not be a related issue; I'm not familiar enough with mulitprocessing to say.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 18:31:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 16:31:11 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1306513871.94.0.0997138494352.issue10424@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, you can upload versions of the same patch with the same name and remove old versions.  The code review tool will remember versions, and it?s easier for human if there?s only one patch.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Fri May 27 18:31:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 16:31:19 +0000
Subject: [issue12042] What's New multiprocessing example error
In-Reply-To: <1304967317.91.0.912225759197.issue12042@psf.upfronthosting.co.za>
Message-ID: <1306513879.59.0.150901448626.issue12042@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22141/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12042>
_______________________________________

From report at bugs.python.org  Fri May 27 18:34:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 27 May 2011 16:34:42 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306512145.22.0.117115529403.issue12196@psf.upfronthosting.co.za>
Message-ID: <BANLkTimbcFdQg4HqxanJbxBLBmFDgj=BYg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> +# A constant likely larger than the underlying OS pipe buffer size.
> +# Windows limit seems to be around 512B, and most Unix kernels have a 64K pipe
> +# buffer size: take 1MB to be sure.
> +PIPE_MAX_SIZE = 1024 * 1024
>
> Hum, I am not sure that the comment is correct. If I understood correctly the usage of this constant: write PIPE_MAX_SIZE into a blocking pipe must block because PIPE_MAX_SIZE is greater than the size of the pipe buffer.

Correct.

> I don't know what happen if you write PIPE_MAX_SIZE into a nonblocking pipe: the beginning of the buffer is written and write() returns something lesser than PIPE_MAX_SIZE?
>

Correct. Note that it could also fail with EAGAIN, that's why I added
an except OSError clause to the write.

> You may specify that if you should greater or equal to os.fpathconf(fd, "PC_PIPE_BUF").
>

I don't understand what you mean. It will be greater than PIPE_BUF,
which is around 4096 (I think 512 guaranteed by POSIX).

> Here you use PIPE_MAX_SIZE*3, not PIPE_MAX_SIZE :-) You can use b'abc' * (support.PIPE_MAX_SIZE // 3), or b'a' * support.PIPE_MAX_SIZE.
>

I know, but that's what the original code did, so I kept it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Fri May 27 18:42:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 May 2011 16:42:53 +0000
Subject: [issue8898] The email package should defer to the codecs module
	for	all aliases
In-Reply-To: <1275677631.44.0.514670475259.issue8898@psf.upfronthosting.co.za>
Message-ID: <1306514573.01.0.618593385796.issue8898@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Not in email5.  The RFC says that if the charset parameter isn't known you just pass it through.  In email6 we will be making a more careful distinction between errors that should be passed silently per the RFC, and ones that should be noisy because the API in question is being used to create the message ab-initio.  (In email5 the exact same machinery is used to create a message from parsed source as is used to create a message programatically, resulting in the silent passing of certain errors that should really be noisy.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8898>
_______________________________________

From report at bugs.python.org  Fri May 27 18:45:37 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 27 May 2011 16:45:37 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1306514737.18.0.568822302015.issue12192@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> Comment: This rule applies to special methods like __getitem__
> and __setitem__. 'lis.append(item)' is equivalent to
> lis.__setitem__(len(lis):len(lis), item), so it should not be so
> surprising that it has the same return.

It's not true for all special methods.  __iadd__ and __imul__ return the list itself.

That's a minor nitpick though.  +1 on adding "and return None" to the docstrings of methods that often trip people up.  Not everyone will read them, but some people will.

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Fri May 27 18:53:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 16:53:31 +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: <1306515211.94.0.969996662108.issue12191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

As a general rule, rewrapping is not done in patches, it can make review less easy.  The committer can do it, sometimes in a second commit.

I commented on the review page.

----------
nosy: +eric.araujo
title: Shutil - add chown() in order to allow to use user and group name (and not only uid/gid) -> Add shutil.chown to allow to use user and group name (and not only uid/gid)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Fri May 27 18:58:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 May 2011 16:58:41 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306515521.83.0.69520749353.issue11906@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ahem. Interactive mode is an approved method of running Python code, along with batch mode. The core interpreter and stdlib modules should run correctly in both modes. So the entire test suite should pass in both modes too. If the tests are written correctly, failure would indicate a bug in the tested component.

That aside, the doc for test/ does not contain 'recommended' and does not discuss running a single test. What I did is the easiest way on Windows.

In this case, following Andreas' remark, the bug is in the test, not the module, in that it miscalculates the expected output in the corner case of a null program name. At lines 2172 and 2205 in the 3.2.0 version of test_argparse.py, changing

'''usage: {} ...
...
'''.format(self.main_program)

to

prog = self.main_program
...
'''usage: {}{}...
...
'''.format(prog, ' ' if prog else '')

fixes the problem.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri May 27 19:02:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 May 2011 17:02:28 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1306515748.33.0.714178169445.issue10424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What I had in mind for the second test was something that did this (which I think is legal from reading the docs):

   parser.add_argument('foo')
   parser.add_argument('bar', nargs='?', default='eggs')
   with assertRaisesRegex(ArgumentParseError) as cm:
       parser.parse_args([])
   self.assertNotIn('bar', str(cm.exception))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Fri May 27 19:04:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 May 2011 17:04:10 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306515850.56.0.17771573161.issue11906@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Interactive mode is an approved method of running Python code, along
> with batch mode. The core interpreter and stdlib modules should run
> correctly in both modes. So the entire test suite should pass in both
> modes too.
You are right.

> That aside, the doc for test/ does not contain 'recommended' and does
> not discuss running a single test.
Such guidelines belong more in the devguide than the library doc: http://docs.python.org/devguide/runtests

> What I did is the easiest way on Windows.
I cannot argue with you on that :)

> In this case, following Andreas' remark, the bug is in the test, not
> the module, in that it miscalculates the expected output in the
> corner case of a null program name.
Since it?s an easy patch in the test file, +1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri May 27 19:07:49 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 27 May 2011 17:07:49 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306516069.55.0.369897883878.issue11906@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

> Interactive mode is an approved method of running Python code, along with batch mode. 

That is not guaranteed for any particular piece of Python code in the standard library. In particular it is not amenable to test automation, so it is certainly not a requirement that tests pass in this mode. (What is the *use case* for running a command line argument parser in interactive mode?)

I'm certainly not opposed to fixing tests so that they do pass when run like this, but I disagree that it is a "bug".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri May 27 19:10:02 2011
From: report at bugs.python.org (Emmanuel Decitre)
Date: Fri, 27 May 2011 17:10:02 +0000
Subject: [issue6717] Some problem with recursion handling
In-Reply-To: <1250518561.04.0.421053701967.issue6717@psf.upfronthosting.co.za>
Message-ID: <1306516202.69.0.406669918605.issue6717@psf.upfronthosting.co.za>


Emmanuel Decitre <emmdec at googlemail.com> added the comment:

Issue reproduceable on 3.2 (r32:88445) with drag_bug_is_nesting_events.py

----------
nosy: +Emmanuel.Decitre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6717>
_______________________________________

From report at bugs.python.org  Fri May 27 19:50:30 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 27 May 2011 17:50:30 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1306518630.08.0.58663054069.issue10424@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22155/issue10424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Fri May 27 19:57:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 May 2011 17:57:20 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1306519040.76.0.658254788508.issue11969@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After looking at the doc chapter, I get that 'if __name__' block is needed on Windows.

OK. batch mode with if __name__ block:

testmp.py
---------
print('Top of Module')
class C:
    def f(s): print('Method C.f')

if __name__ == '__main__':
    print('Start of main block')
    import multiprocessing
    p = multiprocessing.Process(target=C.f, args=(C(),))
    p.start()
    p.join()

command-prompt..\python32> python @misc2\testmp.py

output (similar to that of OP):

Top of Module
Start of main block
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\pickle.py", line 679, in save_global
    klass = getattr(mod, name)
AttributeError: 'module' object has no attribute 'f'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "@misc2\testmp.py", line 9, in <module>
    p.start()
  File "C:\Programs\Python32\lib\multiprocessing\process.py", line 130, in start

    self._popen = Popen(self)
  File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 267, in __init__
    dump(process_obj, to_child, HIGHEST_PROTOCOL)
  File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 190, in dump
    ForkingPickler(file, protocol).dump(obj)
  File "C:\Programs\Python32\lib\pickle.py", line 237, in dump
    self.save(obj)
  File "C:\Programs\Python32\lib\pickle.py", line 344, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Programs\Python32\lib\pickle.py", line 432, in save_reduce
    save(state)
  File "C:\Programs\Python32\lib\pickle.py", line 299, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Programs\Python32\lib\pickle.py", line 623, in save_dict
    self._batch_setitems(obj.items())
  File "C:\Programs\Python32\lib\pickle.py", line 656, in batch_setitems
    save(v)
  File "C:\Programs\Python32\lib\pickle.py", line 299, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Programs\Python32\lib\pickle.py", line 683, in save_global
    (obj, module, name))
_pickle.PicklingError: Can't pickle <function f at 0x00B4B4B0>: it's not found as __main__.f

C:\Programs\Python32>Top of Module
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Programs\Python32\lib\multiprocessing\forking.py", line 370, in main
    self = load(from_parent)
EOFError

The essential problem seems to be the attempt to pickle the method attribute of the class as a class attribute of the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Fri May 27 19:59:21 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Fri, 27 May 2011 17:59:21 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
	__init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1306519161.61.0.333244737913.issue12085@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

I've added passing __init__ an undeclared keyword argument as an example to the comment following your suggestion. I've also reworded the comment to make it sound better to me and added a full stop. :-)

----------
Added file: http://bugs.python.org/file22156/_child_created_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Fri May 27 20:06:49 2011
From: report at bugs.python.org (David Siroky)
Date: Fri, 27 May 2011 18:06:49 +0000
Subject: [issue12197] non-blocking SSL write in Windows sends large data but
	raises exception
In-Reply-To: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>
Message-ID: <1306519609.32.0.152577977388.issue12197@psf.upfronthosting.co.za>


New submission from David Siroky <siroky at dasir.cz>:

Trying to send large bulk of data in MS Windows via non-blocking SSLSocket raises an exception but part of the data is delivered.

E.g.

ssl_socket.write(b"a" * 200000)

raises

ssl.SSLError: [Errno 3] _ssl.c:1126: The operation did not complete (write)

There is no way to get the sent bytes count which is essential in non-blocking communication.

ssl_socket.send() returns 0. This should be unified with posix behavior.

----------
components: Extension Modules, Windows
files: ssl_sock_test.py
messages: 137092
nosy: dsiroky
priority: normal
severity: normal
status: open
title: non-blocking SSL write in Windows sends large data but raises exception
type: behavior
versions: Python 2.6, Python 3.2
Added file: http://bugs.python.org/file22157/ssl_sock_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12197>
_______________________________________

From report at bugs.python.org  Fri May 27 20:44:26 2011
From: report at bugs.python.org (Greg Steuck)
Date: Fri, 27 May 2011 18:44:26 +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: <1306521866.64.0.0795641748962.issue12198@psf.upfronthosting.co.za>


New submission from Greg Steuck <gnezdo+pythonbugs at google.com>:

zipfile.py displays warning when trying to write files timestamped before 1980.

% cat /tmp/a.py
import zipfile
import os

z = zipfile.ZipFile('/tmp/a.zip', 'w')
open("/tmp/a", "w")
os.utime("/tmp/a", (0,0))
z.write("/tmp/a", "a")
% python -V
Python 2.6.5
% uname -mo
x86_64 GNU/Linux
% uname -mor
2.6.32-gg426-generic x86_64 GNU/Linux
% python /tmp/a.py
/usr/lib/python2.6/zipfile.py:1047: DeprecationWarning: struct integer overflow masking is deprecated
 self.fp.write(zinfo.FileHeader())
/usr/lib/python2.6/zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= number <= 65535
 self.fp.write(zinfo.FileHeader())
/usr/lib/python2.6/zipfile.py:1123: DeprecationWarning: struct integer overflow masking is deprecated
 self.close()
/usr/lib/python2.6/zipfile.py:1123: DeprecationWarning: 'H' format requires 0 <= number <= 65535
 self.close()

Similar to, but different from http://bugs.python.org/issue1526.

Amaury Forgeot d'Arc says:

The ZIP file format is unable to store dates before 1980.  With version 3.2, your script even raises an exception.  Please file this in a different issue.

----------
components: Library (Lib)
messages: 137093
nosy: gnezdo
priority: normal
severity: normal
status: open
title: zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= number <= 65535
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12198>
_______________________________________

From report at bugs.python.org  Fri May 27 20:47:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 May 2011 18:47:55 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306522075.39.0.694078073313.issue11906@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Unless the doc for a module explicitly diclaims interactive mode (as does multiproccessing), it should run interactively as documented. Batch and interactive are not mutually exclusive; python -i runs a file in batch mode and switches to interactive mode. IDLE *always* runs files this way!

Interactive exploration is a recommended way to learn Python. I agree that it would be tedious to explore the usage of argparse, for instance, by typing everything at the interactive prompt. But one could, for instance, write a file that puts fake content into sys.argv, sets up option and arg specs, and parses. After running the file in IDLE (or with python -i), one might interactively modify sys.argv or the specs and reparse to see what changes.

In any case, using a module interactively and running its test interactively are different things. If a test cannot run interactively, it should be marked as 'skip if interactive' just as with all the other skip conditions. (Skip if not self.program_name might do it.) But this is all moot for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Fri May 27 20:57:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2011 18:57:51 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <E1QQ2EI-0002af-Gg@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 9b11cc4e2918 by Benjamin Peterson in branch 'default':
reflect with statements with multiple items in the AST (closes #12106)
http://hg.python.org/cpython/rev/9b11cc4e2918

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Fri May 27 20:58:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 May 2011 18:58:59 +0000
Subject: [issue12192] Doc that collection mutation methods return item or None
In-Reply-To: <1306445590.95.0.898960015708.issue12192@psf.upfronthosting.co.za>
Message-ID: <1306522739.17.0.625385897423.issue12192@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Darn, I knew there might be an exception I was overlooking ;-).
Anyway, I considered the general statements to be drafts, to be rewritten after comments.

As to the footnote (9) suggestion: the set and dict sections list each method separately with normal entries, so there is not no problem with adding 'and returns None' to those that need it. The mutable sequence section is unique in instead putting all the methods in a condensed table. 'return None' could be added to some lines in the table, but not others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12192>
_______________________________________

From report at bugs.python.org  Fri May 27 21:55:24 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 May 2011 19:55:24 +0000
Subject: [issue12199] Unify TryExcept and TryFinally
In-Reply-To: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>
Message-ID: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

You can write them as one compound statement in Python, so there's no point in having two ast classes.

----------
components: Interpreter Core
files: try.patch
keywords: patch
messages: 137097
nosy: benjamin.peterson, ncoghlan
priority: normal
severity: normal
status: open
title: Unify TryExcept and TryFinally
versions: Python 3.3
Added file: http://bugs.python.org/file22158/try.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12199>
_______________________________________

From report at bugs.python.org  Fri May 27 23:37:03 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 27 May 2011 21:37:03 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306532223.16.0.250208370477.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I seem to be unable to log in to rietveld, so I'll reply here.

>> result += decomp.decompress(data)
> Is this efficient?  I understood that other Python implementations
> had poorly performing str.__iadd__, and therefore that using a list
> was the common idiom (using ?return b''.join(result)? at the end).

Good point. I hadn't thought about other implementations.

Also, you're right about the superfluous comments in test_bz2; I'll do a
general cleanup of the test code soon.

> Looks good.  I only have one paranoid comment: since the tests use
> self.TEXT * 5 to create multiple streams, the ordering of the files is
> not tested.  IOW, the code could mix-up the order of the files and the
> tests would not catch that.  Is it a concern?

I wouldn't think so. It's not as though there is an index that the code
looks at to find the location of each stream. It just reads the data from
the file and if it reaches the end of one stream, it assumes that the
following data is a new stream, and decompresses it accordingly.

That said, I wouldn't be opposed to adding a test for that sort of thing
(just for paranoia's sake :P) if it doesn't involve adding large amounts
of additional binary data in the file. I'll come back to it once I've
tidied up the existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sat May 28 00:02:21 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 27 May 2011 22:02:21 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306533741.19.0.174165221569.issue11906@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

> it should run interactively as documented.

Where is it documented that all tests will run from the IDLE prompt?

I have *never* heard this claim before. I have nothing against tests supporting this, but those who want it to happen will have to do the work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Sat May 28 01:15:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 May 2011 23:15:51 +0000
Subject: [issue11689] sqlite: Incorrect unit test fails to detect failure
In-Reply-To: <1301178520.82.0.473046584416.issue11689@psf.upfronthosting.co.za>
Message-ID: <1306538151.7.0.443077734204.issue11689@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11689>
_______________________________________

From report at bugs.python.org  Sat May 28 01:22:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 May 2011 23:22:03 +0000
Subject: [issue11653] Problems with some tests using -j2
In-Reply-To: <1300900834.38.0.866909082776.issue11653@psf.upfronthosting.co.za>
Message-ID: <1306538523.59.0.308275782004.issue11653@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11653>
_______________________________________

From report at bugs.python.org  Sat May 28 02:51:36 2011
From: report at bugs.python.org (Mike Solomon)
Date: Sat, 28 May 2011 00:51:36 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306505404.19.0.825669009534.issue12190@psf.upfronthosting.co.za>
Message-ID: <BANLkTinJ9haw_dMebw9zUY9JQP6qpi2eYQ@mail.gmail.com>


Mike Solomon <msolo at gmail.com> added the comment:

The in-memory fix is really the most important - the disk space was a bonus
and an easy metric to gather.

Unfortunately, our app won't be upgrading to python 3.x.

On Fri, May 27, 2011 at 7:10 AM, Benjamin Peterson
<report at bugs.python.org>wrote:

>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> As you can see, I've implemented a similar solution in 3.3. It should have
> the same memory savings but not disk space saving. (This would require
> reintroducing the marshal feature for interned strings.)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12190>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22159/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________
-------------- next part --------------
The in-memory fix is really the most important - the disk space was a bonus and an easy metric to gather.??<div><br></div><div>Unfortunately, our app won&#39;t be upgrading to python 3.x.<br><br><div class="gmail_quote">On Fri, May 27, 2011 at 7:10 AM, Benjamin Peterson <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>
Benjamin Peterson &lt;<a href="mailto:benjamin at python.org">benjamin at python.org</a>&gt; added the comment:<br>
<br>
</div>As you can see, I&#39;ve implemented a similar solution in 3.3. It should have the same memory savings but not disk space saving. (This would require reintroducing the marshal feature for interned strings.)<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue12190" target="_blank">http://bugs.python.org/issue12190</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Sat May 28 02:56:41 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 28 May 2011 00:56:41 +0000
Subject: [issue12190] intern filenames in bytecode
In-Reply-To: <1306438213.22.0.314519878777.issue12190@psf.upfronthosting.co.za>
Message-ID: <1306544201.1.0.0649782752944.issue12190@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Okay, I'll close.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12190>
_______________________________________

From report at bugs.python.org  Sat May 28 03:00:12 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 May 2011 01:00:12 +0000
Subject: [issue1189811] pydoc may hide non-private doc strings.
Message-ID: <1306544412.45.0.622694303347.issue1189811@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In the time since 2.3, pydoc.visiblename() has been updated to use the correct definition of visibility.

A "developer" mode that exposes internal details doesn't make sense. When you're developing something and want to see internal details, *look at the code*.

----------
nosy: +ncoghlan
resolution:  -> rejected
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1189811>
_______________________________________

From report at bugs.python.org  Sat May 28 03:07:51 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 28 May 2011 01:07:51 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306544871.61.0.196186986172.issue12084@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

It turns out DeviceIoControl/FSCTL_GET_REPARSE_POINT (in win32_read_link) will only work for us as long as the symlink was created with a full path. Starting at the top level of a source checkout, if I create `os.symlink("README", "README.lnk")` and then do `os.stat("..\\README.lnk")` from up a directory (or any other directory), DeviceIoControl can only find out that the symlink was created with "README", so the reparse tag it knows about is "README", which doesn't really help us in figuring out where that file is actually located. Everything is fine if I create the symlink with full paths.

I'm in the middle of refactoring this to work with GetFinalPathNameByHandle. I had thought about a quick-and-dirty solution of modifying os.symlink to convert all paths into fully qualified paths in order to give DeviceIoControl the info it needs for os.stat...but that doesn't help for any previously created links, or for any links created by Microsoft tools such as the "mklink" command line tool (it doesn't set the reparse tag with a fully qualified path either).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Sat May 28 03:55:24 2011
From: report at bugs.python.org (library.engine)
Date: Sat, 28 May 2011 01:55:24 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1306547724.75.0.210574417432.issue8583@psf.upfronthosting.co.za>


library.engine <library.engine at gmail.com> added the comment:

I second request for tag names not prefixed with a root namespace in python,
mostly because of ugly code, as performance degradation is negligible on relatively small files. But this ubiquitous repeating (even in the case if you're appending a variable to every tag name) is just against the DRY principle, and I don't like it.
I think an extra option to pass list of namespaces that should NOT be prepended to the tag names would be sufficient.

----------
nosy: +library.engine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8583>
_______________________________________

From report at bugs.python.org  Sat May 28 04:08:47 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 28 May 2011 02:08:47 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>


New submission from Mark Hammond <skippy.hammond at gmail.com>:

Probably in all versions, but certainly in 2.7.

If you create an installer with bdist_wininst and specify an install_script, that script is not run on uninstallation.

See attached test case: setup.py specifies an install_script which just appends argv to %TEMP%/uninstall-test.txt.

* Create the installer with "python setup.py bdist_wininst"
* Execute the installer (ie, "dist\hello-0.1.win32.exe")
* Check %TEMP%/uninstall-test.txt - it should have 1 line:
['o:\\src\\python-2.6\\Scripts\\hello-install.py', '-install']
* Uninstall the package.
* Check %TEMP%/uninstall-test.txt - it *should* have a new line reflecting the uninstall.  Instead it is unchanged.

To get more info:
* Reinstall the package.
* Manually uninstall using the cmdline (with adjusted paths)
C:\> "c:\python26\Removehello.exe" -u "c:\python26\hello-wininst.log" > %TEMP%\delme.out 2>&1

Check the contents of %TEMP%\delme.out - you will see:
*** Could not load Python ****** Could not run installation script ***

Digging into the source code of install.c - the problem is that although the Python DLL name is parsed from the log file, this isn't reflected in the global variables python_dir or pythondll - so they remain empty strings and attempting to load the empty string as Python causes the error messages.

----------
assignee: tarek
components: Distutils
files: setup.py
messages: 137105
nosy: eric.araujo, mhammond, tarek
priority: normal
severity: normal
status: open
title: bdist_wininst install_script not run on uninstall
type: behavior
Added file: http://bugs.python.org/file22160/setup.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12200>
_______________________________________

From report at bugs.python.org  Sat May 28 04:09:18 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 28 May 2011 02:09:18 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306548558.29.0.460757767507.issue12200@psf.upfronthosting.co.za>


Changes by Mark Hammond <skippy.hammond at gmail.com>:


Added file: http://bugs.python.org/file22161/hello.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12200>
_______________________________________

From report at bugs.python.org  Sat May 28 04:09:36 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sat, 28 May 2011 02:09:36 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306548576.75.0.0781636414251.issue12200@psf.upfronthosting.co.za>


Changes by Mark Hammond <skippy.hammond at gmail.com>:


Added file: http://bugs.python.org/file22162/hello-install.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12200>
_______________________________________

From report at bugs.python.org  Sat May 28 09:04:35 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 28 May 2011 07:04:35 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1306566275.6.0.0508123572002.issue8583@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I don't see this having much to do with the DRY principle. It's "explicit is better than implicit" and "better safe than sorry" that applies here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8583>
_______________________________________

From report at bugs.python.org  Sat May 28 09:27:47 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 May 2011 07:27:47 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1306567667.78.0.091594401504.issue8583@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I recommend to revert this change. It seems that some users are opposed to any kind of folding (as my earlier folding experiment has demonstrated); users who *really* don't want to see the history would need to step forward and request a per-user option to suppress it.

I think the real solution to information flooding here is to have users split larger issues into smaller ones, only discuss one issue at the time, etc.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8583>
_______________________________________

From report at bugs.python.org  Sat May 28 09:28:52 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 May 2011 07:28:52 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1306567732.79.0.786988842595.issue8583@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
Removed message: http://bugs.python.org/msg137107

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8583>
_______________________________________

From report at bugs.python.org  Sat May 28 09:48:15 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 28 May 2011 07:48:15 +0000
Subject: [issue12163] str.count
In-Reply-To: <1306203026.57.0.880785470377.issue12163@psf.upfronthosting.co.za>
Message-ID: <1306568895.78.0.966276514425.issue12163@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
components: +Interpreter Core
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12163>
_______________________________________

From report at bugs.python.org  Sat May 28 09:50:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2011 07:50:10 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <E1QQEHh-0002KE-4O@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset ecf0ef85c72a by Ned Deily in branch '2.7':
Issue #9670: Increase the default stack size for secondary threads on
http://hg.python.org/cpython/rev/ecf0ef85c72a

New changeset 0cded2f2cea3 by Ned Deily in branch '3.1':
Issue #9670: Increase the default stack size for secondary threads on
http://hg.python.org/cpython/rev/0cded2f2cea3

New changeset 8a484090da7e by Ned Deily in branch '3.2':
Issue #9670: Increase the default stack size for secondary threads on
http://hg.python.org/cpython/rev/8a484090da7e

New changeset 8220f68f1229 by Ned Deily in branch 'default':
Issue #9670: Increase the default stack size for secondary threads on
http://hg.python.org/cpython/rev/8220f68f1229

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Sat May 28 09:53:23 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 May 2011 07:53:23 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1306569203.33.0.235852891963.issue9670@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Version 4 looks good and the tests pass on OS X with pydebug enabled.  Applied in 2.7 (for release in 2.7.2), 3.1 (for 3.1.4). 3.2 (for 3.2.1), and default (for 3.3).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Sat May 28 10:15:27 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 28 May 2011 08:15:27 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306570527.9.0.195949367555.issue12196@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Out of interest, is there any reason that the configure check for pipe2 is a special case near the bottom of configure.in instead of with all the other function checks in the AC_CHECK_FUNCS[] section in the middle?
I know this patch didn't write the configure check but maybe it could be changed.

Also, the pure python implementation of subprocess for posix can now be updated to use pipe2 if it exists (previously on _posixsubprocess.c used it).

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 11:04:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 09:04:11 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1306573451.53.0.567328542281.issue12188@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure it's worth adding this to the PEP 7.  The PEP is about conventions and style not idioms.
PEP 8 has a section about "Programming Recommendations" that contains a few idioms, but since PEP 7 doesn't have an equivalent section, I think that explaining this idiom (and not others) will look out of place.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12188>
_______________________________________

From report at bugs.python.org  Sat May 28 11:20:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 09:20:19 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306574419.22.0.581022292618.issue11906@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Terry, I think you can apply the patch you proposed in msg137085 and close this issue.
If the recommended structure of test files is not documented, a section in the devguide should be added, but that's another issue.  (FWIW I'm not even sure there's a recommended structure, if that's the case we should figure out one, document it, and use it in all the tests.)

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Sat May 28 11:25:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 09:25:25 +0000
Subject: =?utf-8?q?=5Bissue10449=5D_=E2=80=9Cos=2Eenviron_was_modified_by_test=5Fh?=
	=?utf-8?q?ttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1306574725.31.0.426918285643.issue10449@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Python 3.1.4 should be released today, so I think it's too late for this to be fixed.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10449>
_______________________________________

From report at bugs.python.org  Sat May 28 11:39:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 09:39:09 +0000
Subject: =?utf-8?q?=5Bissue10449=5D_=E2=80=9Cos=2Eenviron_was_modified_by_test=5Fh?=
	=?utf-8?q?ttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1306575549.3.0.62023935066.issue10449@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The release date of 3.1.4 is actually June 11th.  Today will be released an RC though, so what I said should still apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10449>
_______________________________________

From report at bugs.python.org  Sat May 28 12:00:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 10:00:21 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306576821.51.0.117978050324.issue12170@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/issue12170>
_______________________________________

From report at bugs.python.org  Sat May 28 12:01:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 10:01:20 +0000
Subject: [issue9382] os.popen referenced but not documented in Python 3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1306576880.35.0.145181049913.issue9382@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/issue9382>
_______________________________________

From report at bugs.python.org  Sat May 28 12:05:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 10:05:53 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1306577153.83.0.954816283943.issue10224@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/issue10224>
_______________________________________

From report at bugs.python.org  Sat May 28 12:09:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 10:09:02 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1306577342.67.0.58359330825.issue10225@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/issue10225>
_______________________________________

From report at bugs.python.org  Sat May 28 12:10:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2011 10:10:41 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <E1QQGTf-0001En-TS@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a2688e252204 by Ned Deily in branch '3.1':
Issue #985064: Make plistlib more resilient to faulty input plists.
http://hg.python.org/cpython/rev/a2688e252204

New changeset f555d959a5d7 by Ned Deily in branch '3.2':
Issue #985064: Make plistlib more resilient to faulty input plists.
http://hg.python.org/cpython/rev/f555d959a5d7

New changeset d0bc18a50bd1 by Ned Deily in branch 'default':
Issue #985064: Make plistlib more resilient to faulty input plists.
http://hg.python.org/cpython/rev/d0bc18a50bd1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue985064>
_______________________________________

From report at bugs.python.org  Sat May 28 12:19:40 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 May 2011 10:19:40 +0000
Subject: [issue985064] plistlib crashes too easily on bad files
Message-ID: <1306577980.26.0.191026030992.issue985064@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thank you for the patch and tests!  Applied in 3.1 (for 3.1.4), 3.2 (for 3.2.1), and 3.3. (The 2.x version of plistlib differs somewhat from the 3.x version so the patch would need some rework and testing for 2.7; that is probably not worth the effort at this point.)

----------
assignee:  -> ned.deily
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue985064>
_______________________________________

From report at bugs.python.org  Sat May 28 12:22:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 May 2011 10:22:16 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306578136.8.0.148833519215.issue12106@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does this change have a visible effect? If so, can it have some unit test? Otherwise pypy and other alternative implementations are likely to miss this change.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Sat May 28 12:22:36 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 May 2011 10:22:36 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306578156.68.0.563344897897.issue12106@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Sat May 28 12:42:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 28 May 2011 10:42:43 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306570527.9.0.195949367555.issue12196@psf.upfronthosting.co.za>
Message-ID: <BANLkTimQLrN9FN-5LXnPM4iQ=WEs5J-odg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Out of interest, is there any reason that the configure check for pipe2 is a special case near the bottom of configure.in instead of with all the other function checks in the AC_CHECK_FUNCS[] section in the middle?

No clue. I'll fix that.

> Also, the pure python implementation of subprocess for posix can now be updated to use pipe2 if it exists (previously on _posixsubprocess.c used it).

I don't understand the last part :-)
What do you suggest?
Use os.pipe2 if available, otherwise use _posixsubprocess.c (because
it has the advantage of running with the GIL held) if available, and
use os.pipe + fcntl as last resort?

By the way, what's the reason for having a both a Python and a C implementation?
Are they some configurations where _posixsubprocess could not be available?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 12:44:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 28 May 2011 10:44:35 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306579475.6.0.978486031392.issue12196@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 12:47:29 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 28 May 2011 10:47:29 +0000
Subject: =?utf-8?q?=5Bissue10449=5D_=E2=80=9Cos=2Eenviron_was_modified_by_test=5Fh?=
	=?utf-8?q?ttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1306579649.73.0.118502760354.issue10449@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I think, if you speak to RM, you can just have this change in. Don't we get "no commits please" email request from RM with hg or is the branch already cut?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10449>
_______________________________________

From report at bugs.python.org  Sat May 28 13:09:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 May 2011 11:09:16 +0000
Subject: [issue12199] Unify TryExcept and TryFinally
In-Reply-To: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>
Message-ID: <1306580956.22.0.433982811403.issue12199@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

>From my review:

"""One genuine problem with a stale assert and comment in ast.c, and a small objection to style in compile.c (I'd like a new compile_try() function to match the new AST node).

Otherwise looked good in a desk review."""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12199>
_______________________________________

From report at bugs.python.org  Sat May 28 13:15:48 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 May 2011 11:15:48 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306581348.9.0.712762235434.issue12106@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The AST version changed, and, more importantly, if other implementations pick up our AST changes without updating their compilers accordingly, their symbol table analysis and code compilation processes will break.

So yes, the test suite does already cover this change.

For the record:
3.2: ast.__version__ == 82163
3.3: ast.__version__ == 0daa6ba25d9b

(The latter is only the 3.3 AST version for the moment - there are additional AST cleanups planned for 3.3 now that the other projects gave their blessing to do so on python-dev)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Sat May 28 13:33:27 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 28 May 2011 11:33:27 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306582407.36.0.603752661902.issue12196@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

>> Also, the pure python implementation of subprocess for posix can now >> be updated to use pipe2 if it exists (previously on _posixsubprocess.c
>> used it).

> I don't understand the last part :-)
> What do you suggest?

Perhaps, os.pipe2 can be used if available, then a modified version of _posixsubprocess.cloexec_pipe without the check for pipe2 could be used as a fallback.

I'm not sure why there exists both a python and c implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 13:38:28 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 28 May 2011 11:38:28 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306582708.52.0.232327092964.issue12106@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for this answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Sat May 28 13:50:33 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 May 2011 11:50:33 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306583433.69.0.535956672325.issue12106@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

One other thing I should mention is that in a later checkin, Benjamin did add a couple of explicit with statement examples to test_ast. These will fail if other implementations don't update the front end of their compilation processes correctly, so that should eliminate cases of counteracting bugs in the front end and back end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Sat May 28 14:00:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 12:00:36 +0000
Subject: [issue12106] reflect syntatic sugar in with ast
In-Reply-To: <1305755119.66.0.28719139357.issue12106@psf.upfronthosting.co.za>
Message-ID: <1306584036.42.0.307503320836.issue12106@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That would be c4ddb460f4f2.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12106>
_______________________________________

From report at bugs.python.org  Sat May 28 14:16:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 12:16:07 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306584967.67.0.268026650427.issue12185@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Note that usually 'self' is not included in the arguments of methods.  The 3.3 doc correctly uses e.g. copy_sign(other).  A 'd.' could also be added so that the end result looks like:
  d.copy_sign(other)
but it's not mandatory (if done, all the other methods should be updated as well).

----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sat May 28 14:30:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 May 2011 12:30:17 +0000
Subject: =?utf-8?q?=5Bissue10449=5D_=E2=80=9Cos=2Eenviron_was_modified_by_test=5Fh?=
	=?utf-8?q?ttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1306585817.05.0.385723557016.issue10449@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10449>
_______________________________________

From report at bugs.python.org  Sat May 28 14:48:40 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sat, 28 May 2011 12:48:40 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306586920.98.0.321248788973.issue12185@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/issue12185>
_______________________________________

From report at bugs.python.org  Sat May 28 14:49:13 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sat, 28 May 2011 12:49:13 +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: <1306586953.78.0.367649168531.issue11699@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/issue11699>
_______________________________________

From report at bugs.python.org  Sat May 28 15:04:07 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 28 May 2011 13:04:07 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306587847.96.0.869711338658.issue12084@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

To the extent that we can, we should try to support relative symlinks. Absolute symlinks aren't the right thing in some cases, where the symlinks should be movable with their targets. I use relative links extensively.

Is it worth considering changing the current working directory to the same directory as the symlink when calling DeviceIoControl?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Sat May 28 15:05:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2011 13:05:29 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <E1QQJCq-0002wI-I1@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset a2f088cf7ced by Ned Deily in branch '2.7':
Issue #11217: For 64-bit/32-bit Mac OS X universal framework builds,
http://hg.python.org/cpython/rev/a2f088cf7ced

New changeset 7f2e3c466d57 by Ned Deily in branch '3.2':
Issue #11217: For 64-bit/32-bit Mac OS X universal framework builds,
http://hg.python.org/cpython/rev/7f2e3c466d57

New changeset 2936e8f12e4f by Ned Deily in branch 'default':
Issue #11217: For 64-bit/32-bit Mac OS X universal framework builds,
http://hg.python.org/cpython/rev/2936e8f12e4f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Sat May 28 15:12:15 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sat, 28 May 2011 13:12:15 +0000
Subject: =?utf-8?q?=5Bissue11644=5D_Cross-link_2to3_documentation=2C_what=E2=80=99?=
	=?utf-8?q?s_new_and_pyporting_howto?=
In-Reply-To: <1300838396.67.0.863213339568.issue11644@psf.upfronthosting.co.za>
Message-ID: <1306588335.82.0.409894740999.issue11644@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/issue11644>
_______________________________________

From report at bugs.python.org  Sat May 28 15:17:23 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sat, 28 May 2011 13:17:23 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1306588643.55.0.453949743525.issue11203@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/issue11203>
_______________________________________

From report at bugs.python.org  Sat May 28 15:30:58 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 May 2011 13:30:58 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <1306589458.58.0.505848076634.issue11217@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the suggested patch.  In addition to the "installunixtools" target, the "altinstallunixtools" target needed to be updated; it is used by default in the Python 3.x Makefiles.  The applied fix causes the following additional symlinks to be added to the --prefix bin directory for a 64-/32-bit framework install:

py27:  python2.7-32  pythonw2.7-32
       python-32     pythonw-32

py32:  python3.2-32  pythonw3.2-32
       python3-32    pythonw3-32 ["make frameworkinstallunixtools" only]

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Sat May 28 15:53:46 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 28 May 2011 13:53:46 +0000
Subject: [issue12201] Returning FILETIME is unsupported in
	msilib.SummaryInformation.GetProperty()
In-Reply-To: <1306590826.19.0.496191579279.issue12201@psf.upfronthosting.co.za>
Message-ID: <1306590826.19.0.496191579279.issue12201@psf.upfronthosting.co.za>


New submission from Mark Mc Mahon <mtnbikingmark at gmail.com>:

In _msi.c, summary_getproperty() and summary_setproperty() raise an exception if the type being set/got is VT_FILETIME. 

This issue is to track adding support for (or declining to support) FILETIMEs in msilib.SummaryInformation.GetProperty()/SetProperty().

I have included a patch which adds this support (with some basic tests).
Should this function accept/return datetime.datetime - or a timestamp (both require conversion anyway). I have used datetimes in my patch.

----------
components: Windows
files: add_FILETIME_support_to_summary_info.patch
keywords: patch
messages: 137130
nosy: loewis, markm
priority: normal
severity: normal
status: open
title: Returning FILETIME is unsupported in msilib.SummaryInformation.GetProperty()
versions: Python 3.2
Added file: http://bugs.python.org/file22163/add_FILETIME_support_to_summary_info.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12201>
_______________________________________

From report at bugs.python.org  Sat May 28 15:59:29 2011
From: report at bugs.python.org (Jonas H.)
Date: Sat, 28 May 2011 13:59:29 +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: <1306591169.5.0.0401911691777.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Does that look good to you? If it does, I'll go on using the script (http://paste.pocoo.org/show/396661/) on the 3.x docs.

----------
keywords: +patch
Added file: http://bugs.python.org/file22164/p1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Sat May 28 15:59:36 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 28 May 2011 13:59:36 +0000
Subject: [issue12202] Check status returns in
	msilib.SummaryInformation.GetProperty()
In-Reply-To: <1306591176.31.0.169874894705.issue12202@psf.upfronthosting.co.za>
Message-ID: <1306591176.31.0.169874894705.issue12202@psf.upfronthosting.co.za>


New submission from Mark Mc Mahon <mtnbikingmark at gmail.com>:

Per Eric V. Smith's comment issue1104 (msg134976) the return value of the call MsiSummaryInfoGetProperty() in summary_getproperty() (pc\_msi.c) is only checked for the error return ERROR_MORE_DATA.

Other error values should be checked.

----------
messages: 137132
nosy: loewis, markm
priority: normal
severity: normal
status: open
title: Check status returns in msilib.SummaryInformation.GetProperty()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12202>
_______________________________________

From report at bugs.python.org  Sat May 28 16:00:42 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 28 May 2011 14:00:42 +0000
Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by
	one character
In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za>
Message-ID: <1306591242.9.0.208420126856.issue1104@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

Responding to Eric's comments

1. There are only three valid property types returned by MsiInteger, String & FILETIME. (http://msdn.microsoft.com/en-us/library/aa372045%28v=VS.85%29.aspx)

2. That comment makes sense - I have entered a new issue (issue12202) for that.

3. Per 1. - there shouldn't be any other unhandled types. I have entered issue issue12201 to track adding support for FILETIMEs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1104>
_______________________________________

From report at bugs.python.org  Sat May 28 16:23:54 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 28 May 2011 14:23:54 +0000
Subject: [issue12202] Check status returns in
	msilib.SummaryInformation.GetProperty()
In-Reply-To: <1306591176.31.0.169874894705.issue12202@psf.upfronthosting.co.za>
Message-ID: <1306592634.41.0.187735981987.issue12202@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

I have added tests to the patch - but it's not easy to know what would cause an error in MsiSummaryInfoGetProperty which would trigger the new code.

----------
keywords: +patch
Added file: http://bugs.python.org/file22165/ensure_MsiSummaryInfoGetProperty_return_value_checked.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12202>
_______________________________________

From report at bugs.python.org  Sat May 28 16:29:50 2011
From: report at bugs.python.org (Mark Mc Mahon)
Date: Sat, 28 May 2011 14:29:50 +0000
Subject: [issue3099] On windows, "import nul" always succeed
In-Reply-To: <1213319928.58.0.193615390811.issue3099@psf.upfronthosting.co.za>
Message-ID: <1306592990.41.0.928957713952.issue3099@psf.upfronthosting.co.za>


Mark Mc Mahon <mtnbikingmark at gmail.com> added the comment:

I am not sure that I fully understand the issue - but it seems that trunk still has this issue.
As stated by Amaury - this is on DEBUG builds only.

c:\>pcbuild\python_d.exe
Python 3.3a0 (default, May 28 2011, 20:22:11) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import nul
[60967 refs]
>>> import con
^Z
[60986 refs]

c:\>PCbuild\python.exe
Python 3.3a0 (default, May 28 2011, 20:25:13) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import nul
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The parameter is incorrect.
>>> import con
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.
>>>

----------
nosy: +markm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3099>
_______________________________________

From report at bugs.python.org  Sat May 28 16:39:20 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 28 May 2011 14:39:20 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306593560.93.0.196165005371.issue12185@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not talking about the method itself but rather the descriptive text. For example:

copy_sign(other)

    Return a copy of the first operand with the sign set to be the same as the sign of the second operand. 

There is no second operand, unless you consider "self" the first and "other" the second. Which of course is true inside the method, but it reads oddly as a description of the method from the outside.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sat May 28 17:11:00 2011
From: report at bugs.python.org (Tom Loredo)
Date: Sat, 28 May 2011 15:11:00 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1306589458.58.0.505848076634.issue11217@psf.upfronthosting.co.za>
Message-ID: <33b8af0c2cf650ed280261b02756adaf@astro.cornell.edu>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

Thanks for handling this, Ned!  -Tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Sat May 28 17:58:44 2011
From: report at bugs.python.org (sorin)
Date: Sat, 28 May 2011 15:58:44 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306598324.13.0.977529046479.issue11623@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

I think that distutils must me modified to auto detect supported architectures and use them, this without requiring you to hack ARCHFLAGS. 

The number of developers that need to build PPC binaries is at least one order of magnitude lower than the number of users in need of building/installing python packages.

----------
nosy: +sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sat May 28 18:36:57 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 28 May 2011 16:36:57 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306600617.41.0.0485498075.issue12196@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I just nuked the pure Python POSIX subprocess implementation in 70467:75ca834df824.  No need for both implementations.  _posixsubprocess is now the only option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 19:05:21 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 May 2011 17:05:21 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306602321.63.0.382300496827.issue12185@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sat May 28 19:39:02 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 28 May 2011 17:39:02 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306604342.95.0.44324910971.issue12196@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22154/posix_pipe2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 19:39:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 28 May 2011 17:39:09 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306604349.97.0.0393505501292.issue12196@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file22151/support_pipe_max.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 19:45:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 28 May 2011 17:45:42 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306600617.41.0.0485498075.issue12196@psf.upfronthosting.co.za>
Message-ID: <BANLkTimbuuOOuAvzjLZ5=r47uJmJSQGOCQ@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> I just nuked the pure Python POSIX subprocess implementation

Nice.

I've updated both patches to address Victor's comments on test_io and
test_subprocess usage of PIPE_MAX_SIZE, and Ross' comment on pipe2's
configure tests.
I left subprocess use _posixsubprocess.cloexec_pipe, since it leads to
simpler code, especially now that the Python version has been removed.

----------
Added file: http://bugs.python.org/file22166/posix_pipe2.diff
Added file: http://bugs.python.org/file22167/support_pipe_max.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________
-------------- next part --------------
diff -r c5bd972391cd Doc/library/os.rst
--- a/Doc/library/os.rst	Sat May 28 10:00:14 2011 -0700
+++ b/Doc/library/os.rst	Sat May 28 19:07:31 2011 +0200
@@ -1019,6 +1019,17 @@
    Availability: Unix, Windows.
 
 
+.. function:: pipe2(flags=0)
+
+   Create a pipe with *flags* set atomically.
+   *flags* is optional and can be constructed by ORing together zero or more of
+   these values: :data:`O_NONBLOCK`, :data:`O_CLOEXEC`.
+   Return a pair of file descriptors ``(r, w)`` usable for reading and writing,
+   respectively.
+
+   Availability: some flavors of Unix.
+
+
 .. function:: posix_fallocate(fd, offset, len)
 
    Ensures that enough disk space is allocated for the file specified by *fd*
diff -r c5bd972391cd Lib/test/test_posix.py
--- a/Lib/test/test_posix.py	Sat May 28 10:00:14 2011 -0700
+++ b/Lib/test/test_posix.py	Sat May 28 19:07:31 2011 +0200
@@ -477,6 +477,31 @@
             reader, writer = posix.pipe()
             os.close(reader)
             os.close(writer)
+            
+    @unittest.skipUnless(hasattr(os, 'pipe2'), "test needs os.pipe2()")
+    def test_pipe2(self):
+        self.assertRaises(TypeError, os.pipe2, 'DEADBEEF')
+        self.assertRaises(TypeError, os.pipe2, 0, 0)
+
+        # try calling without flag, like os.pipe()
+        r, w = os.pipe2()
+        os.close(r)
+        os.close(w)
+
+        # test flags
+        r, w = os.pipe2(os.O_CLOEXEC|os.O_NONBLOCK)
+        self.addCleanup(os.close, r)
+        self.addCleanup(os.close, w)
+        self.assertTrue(fcntl.fcntl(r, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
+        self.assertTrue(fcntl.fcntl(w, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
+        # try reading from an empty pipe: this should fail, not block
+        self.assertRaises(OSError, os.read, r, 1)
+        # try a write big enough to fill-up the pipe (64K on most kernels): this
+        # should either fail or perform a partial write, not block
+        try:
+            os.write(w, b'x' * support.PIPE_MAX_SIZE)
+        except OSError:
+            pass
 
     def test_utime(self):
         if hasattr(posix, 'utime'):
diff -r c5bd972391cd Modules/posixmodule.c
--- a/Modules/posixmodule.c	Sat May 28 10:00:14 2011 -0700
+++ b/Modules/posixmodule.c	Sat May 28 19:07:31 2011 +0200
@@ -6547,6 +6547,31 @@
 }
 #endif  /* HAVE_PIPE */
 
+#ifdef HAVE_PIPE2
+PyDoc_STRVAR(posix_pipe2__doc__,
+"pipe2(flags=0) -> (read_end, write_end)\n\n\
+Create a pipe with flags set atomically.\
+flags is optional and can be constructed by ORing together zero or more\n\
+of these values: O_NONBLOCK, O_CLOEXEC.\n\
+");
+
+static PyObject *
+posix_pipe2(PyObject *self, PyObject *args)
+{
+    int flags = 0;
+    int fds[2];
+    int res;
+
+    if (!PyArg_ParseTuple(args, "|i:pipe2", &flags))
+        return NULL;
+
+    res = pipe2(fds, flags);
+    if (res != 0)
+        return posix_error();
+    return Py_BuildValue("(ii)", fds[0], fds[1]);
+}
+#endif /* HAVE_PIPE2 */
+
 #ifdef HAVE_WRITEV
 PyDoc_STRVAR(posix_writev__doc__,
 "writev(fd, buffers) -> byteswritten\n\n\
@@ -9441,6 +9466,9 @@
 #ifdef HAVE_PIPE
     {"pipe",            posix_pipe, METH_NOARGS, posix_pipe__doc__},
 #endif
+#ifdef HAVE_PIPE2
+    {"pipe2",           posix_pipe2, METH_VARARGS, posix_pipe2__doc__},
+#endif
 #ifdef HAVE_MKFIFO
     {"mkfifo",          posix_mkfifo, METH_VARARGS, posix_mkfifo__doc__},
 #endif
diff -r c5bd972391cd configure
--- a/configure	Sat May 28 10:00:14 2011 -0700
+++ b/configure	Sat May 28 19:07:31 2011 +0200
@@ -9307,7 +9307,7 @@
  getpriority getresuid getresgid getpwent getspnam getspent getsid getwd \
  if_nameindex \
  initgroups kill killpg lchmod lchown lockf linkat lstat lutimes mbrtowc mkdirat mkfifo \
- mkfifoat mknod mknodat mktime mremap nice openat pathconf pause plock poll \
+ mkfifoat mknod mknodat mktime mremap nice openat pathconf pause pipe2 plock poll \
  posix_fallocate posix_fadvise pread \
  pthread_init pthread_kill putenv pwrite readlink readlinkat readv realpath renameat \
  select sem_open sem_timedwait sem_getvalue sem_unlink sendfile setegid seteuid \
@@ -13824,14 +13824,6 @@
 esac
 
 
-ac_fn_c_check_func "$LINENO" "pipe2" "ac_cv_func_pipe2"
-if test "x$ac_cv_func_pipe2" = x""yes; then :
-
-$as_echo "#define HAVE_PIPE2 1" >>confdefs.h
-
-fi
-
-
 
 
 for h in `(cd $srcdir;echo Python/thread_*.h)`
diff -r c5bd972391cd configure.in
--- a/configure.in	Sat May 28 10:00:14 2011 -0700
+++ b/configure.in	Sat May 28 19:07:31 2011 +0200
@@ -2531,7 +2531,7 @@
  getpriority getresuid getresgid getpwent getspnam getspent getsid getwd \
  if_nameindex \
  initgroups kill killpg lchmod lchown lockf linkat lstat lutimes mbrtowc mkdirat mkfifo \
- mkfifoat mknod mknodat mktime mremap nice openat pathconf pause plock poll \
+ mkfifoat mknod mknodat mktime mremap nice openat pathconf pause pipe2 plock poll \
  posix_fallocate posix_fadvise pread \
  pthread_init pthread_kill putenv pwrite readlink readlinkat readv realpath renameat \
  select sem_open sem_timedwait sem_getvalue sem_unlink sendfile setegid seteuid \
@@ -4244,8 +4244,6 @@
 esac
 
 
-AC_CHECK_FUNC(pipe2, AC_DEFINE(HAVE_PIPE2, 1, [Define if the OS supports pipe2()]), )
-
 AC_SUBST(THREADHEADERS)
 
 for h in `(cd $srcdir;echo Python/thread_*.h)`
diff -r c5bd972391cd pyconfig.h.in
--- a/pyconfig.h.in	Sat May 28 10:00:14 2011 -0700
+++ b/pyconfig.h.in	Sat May 28 19:07:31 2011 +0200
@@ -560,7 +560,7 @@
 /* Define to 1 if you have the `pause' function. */
 #undef HAVE_PAUSE
 
-/* Define if the OS supports pipe2() */
+/* Define to 1 if you have the `pipe2' function. */
 #undef HAVE_PIPE2
 
 /* Define to 1 if you have the `plock' function. */
-------------- next part --------------
diff -r d0bc18a50bd1 Lib/test/support.py
--- a/Lib/test/support.py	Sat May 28 03:09:33 2011 -0700
+++ b/Lib/test/support.py	Sat May 28 18:59:15 2011 +0200
@@ -48,7 +48,7 @@
     "threading_cleanup", "reap_children", "cpython_only", "check_impl_detail",
     "get_attribute", "swap_item", "swap_attr", "requires_IEEE_754",
     "TestHandler", "Matcher", "can_symlink", "skip_unless_symlink",
-    "import_fresh_module", "requires_zlib"
+    "import_fresh_module", "requires_zlib", "PIPE_MAX_SIZE"
     ]
 
 class Error(Exception):
@@ -409,6 +409,13 @@
 
 IPV6_ENABLED = _is_ipv6_enabled()
 
+
+# A constant likely larger than the underlying OS pipe buffer size.
+# Windows limit seems to be around 512B, and most Unix kernels have a 64K pipe
+# buffer size: take 1M to be sure.
+PIPE_MAX_SIZE = 1024 * 1024
+
+
 # decorator for skipping tests on non-IEEE 754 platforms
 requires_IEEE_754 = unittest.skipUnless(
     float.__getformat__("double").startswith("IEEE"),
diff -r d0bc18a50bd1 Lib/test/test_io.py
--- a/Lib/test/test_io.py	Sat May 28 03:09:33 2011 -0700
+++ b/Lib/test/test_io.py	Sat May 28 18:59:15 2011 +0200
@@ -2683,7 +2683,7 @@
             # The buffered IO layer must check for pending signal
             # handlers, which in this case will invoke alarm_interrupt().
             self.assertRaises(ZeroDivisionError,
-                              wio.write, item * (1024 * 1024))
+                        wio.write, item * (support.PIPE_MAX_SIZE // len(item)))
             t.join()
             # We got one byte, get another one and check that it isn't a
             # repeat of the first one.
diff -r d0bc18a50bd1 Lib/test/test_subprocess.py
--- a/Lib/test/test_subprocess.py	Sat May 28 03:09:33 2011 -0700
+++ b/Lib/test/test_subprocess.py	Sat May 28 18:59:15 2011 +0200
@@ -489,24 +489,21 @@
         # This test will probably deadlock rather than fail, if
         # communicate() does not work properly.
         x, y = os.pipe()
-        if mswindows:
-            pipe_buf = 512
-        else:
-            pipe_buf = os.fpathconf(x, "PC_PIPE_BUF")
         os.close(x)
         os.close(y)
         p = subprocess.Popen([sys.executable, "-c",
                               'import sys,os;'
                               'sys.stdout.write(sys.stdin.read(47));'
-                              'sys.stderr.write("xyz"*%d);'
-                              'sys.stdout.write(sys.stdin.read())' % pipe_buf],
+                              'sys.stderr.write("x" * %d);'
+                              'sys.stdout.write(sys.stdin.read())' %
+                              support.PIPE_MAX_SIZE],
                              stdin=subprocess.PIPE,
                              stdout=subprocess.PIPE,
                              stderr=subprocess.PIPE)
         self.addCleanup(p.stdout.close)
         self.addCleanup(p.stderr.close)
         self.addCleanup(p.stdin.close)
-        string_to_write = b"abc"*pipe_buf
+        string_to_write = b"a" * support.PIPE_MAX_SIZE
         (stdout, stderr) = p.communicate(string_to_write)
         self.assertEqual(stdout, string_to_write)
 

From report at bugs.python.org  Sat May 28 19:48:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 17:48:56 +0000
Subject: [issue11906] test_argparse failure in interactive mode
In-Reply-To: <1303442771.01.0.0867760921949.issue11906@psf.upfronthosting.co.za>
Message-ID: <1306604936.64.0.99087285536.issue11906@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I will when I get setup to do that again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11906>
_______________________________________

From report at bugs.python.org  Sat May 28 20:35:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 18:35:30 +0000
Subject: [issue12129] Document Object Model API - validation
In-Reply-To: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>
Message-ID: <1306607730.63.0.883352674783.issue12129@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I suspect you are right, but do not know the rules, and have never used the module. There is no particular person maintaining xml.dom.X at present.

Could you please fill in the ... after the import to give a complete minimal example that fails? Someone could then test it on 3.2

----------
nosy: +terry.reedy
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12129>
_______________________________________

From report at bugs.python.org  Sat May 28 21:17:14 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 28 May 2011 19:17:14 +0000
Subject: [issue12053] Add prefetch() for Buffered IO (experiment)
In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>
Message-ID: <1306610234.1.0.791958193778.issue12053@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

I started a draft in python. I am attaching the _pyio version along with tests. I will continue work on the C implementation and eventually documentation if this is well received. It seems straightforward, I am interested to see what you guys think.

Also, there are now 2 places which use hasattr(self, "peek"). I was wondering if it would make sense to add peek() to BufferedIOBase and raise UnsupportedOperation or return b"".

Some benchmarks..

$ ./python -m timeit -s "from _pyio import open;f = open('LICENSE', 'rb'); b=bytearray(128)" 'while f.prefetch(b, 4, 4): pass'
_pyio.BufferedIOBase.prefetch:
100000 loops, best of 3: 10.6 usec per loop
_pyio.BufferedReader.prefetch:
100000 loops, best of 3: 6 usec per loop

$ ./python -m timeit -s "from _pyio import open;f = open('LICENSE', 'rb');b=bytearray(4);" 'while f.read(4): f.readinto(b)'
100000 loops, best of 3: 5.07 usec per loop

----------
keywords: +patch
Added file: http://bugs.python.org/file22168/issue12053-pyio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12053>
_______________________________________

From report at bugs.python.org  Sat May 28 21:17:32 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 28 May 2011 19:17:32 +0000
Subject: [issue12053] Add prefetch() for Buffered IO (experiment)
In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>
Message-ID: <1306610252.51.0.0276370018619.issue12053@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


Added file: http://bugs.python.org/file22169/issue12053-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12053>
_______________________________________

From report at bugs.python.org  Sat May 28 21:24:58 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 28 May 2011 19:24:58 +0000
Subject: [issue12199] Unify TryExcept and TryFinally
In-Reply-To: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>
Message-ID: <1306610698.82.0.702645835198.issue12199@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the review. New patch.

----------
Added file: http://bugs.python.org/file22170/try2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12199>
_______________________________________

From report at bugs.python.org  Sat May 28 21:39:35 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sat, 28 May 2011 19:39:35 +0000
Subject: [issue11893] Obsolete SSLFakeFile in smtplib?
In-Reply-To: <1303332884.98.0.410323888418.issue11893@psf.upfronthosting.co.za>
Message-ID: <1306611575.17.0.225268591838.issue11893@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

Attached v1 of patch. Please review.

There are some tests using GMail in test_smtpnet.py. They still pass with the patch. I also did manual tests with GMail with both SMTP + starttls and SMTP_SSL.

The idea of the patch is that SMTP.getreply is already doing:
  if self.file is None:
      self.file = self.sock.makefile('rb')
Therefore, the patch invalidates self.file by setting it to None every time self.sock is (re-)assigned to something.

For consistency, setting self.file to None is also done in LMTP.connect when setting self.sock to a Unix socket although it's not necessarily needed there. Not doing this makes the following scenario fail: create an LMTP instance, call connect, send and read some data (self.file gets initialized), call connect again with an Unix socket, reading more data now uses self.file referring to old socket. But I'm not sure if this scenario is a bug or a misuse of the API, aka you shouldn't call connect twice on the same instance.

Note that I didn't test LMTP. Should I or is it obvious enough that the change is ok?

----------
keywords: +patch
nosy: +catalin.iacob
Added file: http://bugs.python.org/file22171/remove_sslfakefile_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11893>
_______________________________________

From report at bugs.python.org  Sat May 28 21:42:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 19:42:09 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1306611729.68.0.107395742186.issue12134@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>From just reading the docs, it appears that json.dump(obj,fp) == fp.write(json.dumps(obj)) and it is easy to wonder why .dump even exists, as it seems a trivial abbreviation (and why not .dump and .dumpf instead). Since, '_one_shot' and 'c_make_encoder' are not mentioned in the doc, there is no hint from these either. So I think a doc addition is needed.

The benchmark is not completely fair as the .dumps timing omits the write call. For the benchmark, that would be trivial. But in real use on multitasking systems with slow (compared to cpu speed) output channels, the write time might dominate.  I can even imagine .dump sometimes winning by getting chunks into a socket buffer and possibly out on the wire, almost immediately, instead of waiting to compute the entire output, possibly interrupted by task swaps. So I presume *this* is at least part of the reason for the incremental .dump.

I changed 'pass' to 'print(bug)' in class writable and verified that .dump is *very* incremental. Even '[' and ']' are separate outputs.

DOC suggestion: (limited to CPython since spec does not prohibit naive implementation of .dump given above) After current .dumps line, add

"In CPython, json.dumps(o), by itself, is faster than json.dump(o,f), at the expense of using more space, because it creates the entire string at once, instead of incrementally writing each piece of o to f. However, f.write(json.dumps(o)) may not be faster."

----------
keywords: +patch
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sat May 28 21:43:56 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Sat, 28 May 2011 19:43:56 +0000
Subject: [issue12177] re.match raises MemoryError
In-Reply-To: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>
Message-ID: <1306611836.28.0.0725696673474.issue12177@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

Here are some windows results with Python 2.7:

>>> import re
>>> re.match("()*?1", "1")
<_sre.SRE_Match object at 0x025C0E60>
>>> re.match("()+?1", "1")
>>> re.match("()+?1", "11")
<_sre.SRE_Match object at 0x025C0E60>
>>> re.match("()*?1", "11")
<_sre.SRE_Match object at 0x025C3C60>
<_sre.SRE_Match object at 0x025C3C60>
>>> re.match("()*?1", "a1")

Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    re.match("()*?1", "a1")
  File "C:\Python27\lib\re.py", line 137, in match
    return _compile(pattern, flags).match(string)
MemoryError
>>> re.match("()+?1", "a1")

Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    re.match("()+?1", "a1")
  File "C:\Python27\lib\re.py", line 137, in match
    return _compile(pattern, flags).match(string)
MemoryError

Note that when matching to a string starting with "1", the matcher will not throw a MemoryError.

----------
nosy: +Matthew.Boehm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12177>
_______________________________________

From report at bugs.python.org  Sat May 28 21:44:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 19:44:09 +0000
Subject: [issue12137] Error EBADF in test_urllibnet
In-Reply-To: <1305995654.0.0.162674044436.issue12137@psf.upfronthosting.co.za>
Message-ID: <1306611849.28.0.091657855051.issue12137@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: EBADF in test_urllibnet -> Error EBADF in test_urllibnet

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12137>
_______________________________________

From report at bugs.python.org  Sat May 28 21:50:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 19:50:50 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1306612250.42.0.728942686192.issue12142@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If you are able to rebuild Python, have you tried running the ctypes test after rebuilding with this change? And, does the test cover the internal uses of _array_type?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12142>
_______________________________________

From report at bugs.python.org  Sat May 28 21:54:37 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 28 May 2011 19:54:37 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306612477.91.0.540638445207.issue12196@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Include an appropriate Version Added annotation in the pipe2 documentation.

Otherwise the current patches look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 21:55:49 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sat, 28 May 2011 19:55:49 +0000
Subject: [issue11785] email subpackages documentation problems
In-Reply-To: <1302105466.45.0.930997240631.issue11785@psf.upfronthosting.co.za>
Message-ID: <1306612549.53.0.0542243656092.issue11785@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/issue11785>
_______________________________________

From report at bugs.python.org  Sat May 28 22:05:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 May 2011 20:05:23 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306613123.06.0.137057946108.issue12196@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the record (for people reading this ticket later), the removal of the python version of the unix subprocess code was discussed on IRC, and it was clarified there that the reason for removing it is not that it duplicates the C code.  We like having python implementations of C code where possible, but the key here is "where possible".  The python version of the Unix subprocess code cannot be made to work correctly, it is necessary to drop into C to get the semantics correct.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sat May 28 22:08:17 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 20:08:17 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1306613297.3.0.0774139961413.issue12144@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Exceptions with traceback are ordinary behavior issues. 'Crash' means segfault or equivalent on Windows. And Jesus is correct.

In general, include system with reports.
With 3.2.0 IDLE on Winxp, adjusted 3.x code

import urllib.request as ur, http.cookiejar as ck
cookie_jar = ck.CookieJar()
request = ur.Request('http://gdyn.cnn.com/1.1/1.gif?1301540335193')
conn = ur.urlopen(request)
cookie_jar.make_cookies(conn, request)

produces essentially same traceback ending in AttributeError.
I did not try the patch.

----------
nosy: +terry.reedy
stage:  -> test needed
type: crash -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Sat May 28 22:38:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 20:38:16 +0000
Subject: [issue12148] Clarify "or-ing together" doctest option flags
In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>
Message-ID: <1306615096.2.0.700504575494.issue12148@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The basic fix is to replace the fake verb 'to or', conjugated not really properly as "or's" or "or'ing", with the real noun 'bitwise-or'.

help(doctest.testmod)
...
    Optional keyword arg "optionflags" or's together module constants,
    and defaults to 0.  This is new in 2.3.  Possible values (see the
    docs for details):

Eliminate 'this is new...' here and above. Suggested replacement:

    Optional keyword arg "optionflags" (default 0) is the bitwise-or
    of the following module constants (see the docs for details):

help(doctest.testfile)
...
    Optional keyword arg "optionflags" or's together module constants,
    and defaults to 0.  Possible values (see the docs for details):

Same replacement (whatever we decide on).

Lib 25.2.4. Basic API
doctest.testfile entry:
...
Optional argument optionflags or?s together option flags. See section Option Flags and Directives.

->
Optional argument optionflags is the bitwise-or of options flags. See section Option Flags and Directives.

doctest.testmode entry refers back to above.

25.2.3.5. Option Flags and Directives

doctest.COMPARISON_FLAGS 
A bitmask or?ing together all the comparison flags above.
doctest.REPORTING_FLAGS 
A bitmask or?ing together all the reporting flags above.

A bitmask that is the bitwise-or of all the comparison flags above.
ditto with 'reporting' instead.

-or-
A bitmask -- the bitwise-or of ...

I think this is all. Searching on "or'" does not work because sphinx nicely replaces "'" with a non-ascii unicode char ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12148>
_______________________________________

From report at bugs.python.org  Sat May 28 22:55:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 20:55:19 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1306616119.25.0.160537874438.issue12155@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The proposed change adds about 7 lines to show the 'trick' of putting num-worker Nones on the queue. I think that is worth it.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Sat May 28 23:30:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 21:30:46 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1306618246.68.0.46665882133.issue12157@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I ran with 3.2, winxp with "if __name__ == '__main__':" added after the def statement (without this, process spawned 150 processes before I got logged out) and ()s added to prints. Hung on pool.join as OP said. I could only stop by closing command window as ^C was ignored. Any new test should have a timeout ;-).

----------
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sat May 28 23:59:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 21:59:27 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306619967.54.0.339467441473.issue12162@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The doc consistently does NOT quote re's in the text. Rather, they are shaded gray, both in Windows help version and html version. So this one should not be treated differently.

Most of the confusion reported is due to not reading the intro paragraphs. I almost suggested closing this without action. However,  after saying to use the r prefix, the doc omits them from examples when not absolutely needed. In particular,

>>> m = re.search('(?<=-)\w+', 'spam-egg')

Why does \w work without being doubled or protected (and it does, I checked), while \1 does not? Hell if I know. So even though that example works, it should be changed. The doc should teach the rule "if strings contains '\', prefix with 'r'" rather than "test and add 'r' if it fails", or "learn the exact list of when needed", which is not given and unknown to me and most any beginner.

I advocate the same practice in the RE How To, which also has at least one example with '\' but without 'r':
>>> p = re.compile('\d+')

I do not think we need another example other than those in the text.

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12162>
_______________________________________

From report at bugs.python.org  Sun May 29 00:06:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2011 22:06:18 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306620378.37.0.375666358245.issue12185@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Return a copy of *self* with the sign set to be the same as the sign of *other*.

seems clearer to me.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sun May 29 00:10:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 28 May 2011 22:10:29 +0000
Subject: [issue12157] join method of multiprocessing Pool object hangs if
	iterable argument of pool.map is empty
In-Reply-To: <1306150966.12.0.634928882921.issue12157@psf.upfronthosting.co.za>
Message-ID: <1306620629.07.0.0620410051897.issue12157@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

When map is called, a MapResult object is created, which adds itself to the Pool's result cache.
When the pool is shut down, the result handler thread waits until the cache drains (while cache and thread._state != TERMINATE). But since no result is posted to the result queue (since the iterable is empty), the result handler never receives any task, and never gets to drain the cache. It thus waits forever on the recv on the result queue.

----------
nosy: +charles-francois.natali

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12157>
_______________________________________

From report at bugs.python.org  Sun May 29 00:27:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 May 2011 22:27:27 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306621647.79.0.975921378931.issue12162@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why it works is due to a quirk in the handling of python strings: if an apparent escape sequence doesn't "mean anything", it is retained verbatim, including the '\' character.  This is documented in http://docs.python.org/reference/lexical_analysis.html#string-literals:

"Unlike Standard C, all unrecognized escape sequences are left in the string unchanged, i.e., the backslash is left in the string. (This behavior is useful when debugging: if an escape sequence is mistyped, the resulting output is more easily recognized as broken.)"

It is *very* unwise to depend on this behavior for anything except debugging, therefore those examples which do are, in my opinion, wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12162>
_______________________________________

From report at bugs.python.org  Sun May 29 00:39:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 May 2011 22:39:00 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306622340.67.0.0692591604937.issue11623@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

All that said, the best solution to the problem is to use an appropriately configured Python for the task at hand.  If you want to build Python executables that are compatible with older OS X versions and Mac hardware (in particular, all machines capable of running OS X 10.4, 10.5, and 10.6), then you should be using something like the traditional python.org 32-bit-only installer configuration (i386/ppc, deployment target=10.3). And to build that Python or extension modules for it on OS X 10.6, you need to have Xcode 3 installed.  End of story.

However, if you don't need that kind of backward compatibility - either you're just running on your own 10.6 (or later) system or are only targeting 10.6+ systems, then you should be using something like the python.org 64-/32- installer configuration (x86_64/i386, deployment target=10.6).  For that you should be able to build Python or extension modules with either Xcode 4 or Xcode 3.

If you are targeting for 10.5 Intel-only and above and want to use Xcode 4, you would need a Python with a slightly different configuration (i.e. with a 10.5 deployment target); we don't currently supply an installer that meets that specialized (and presumably rapidly diminishing) need for x86_64 on 10.5 but it isn't that difficult to build yourself if you really need it.

So, if you choose the right binary installer for the task, there *shouldn't* be any issues with using Xcode 4.  If you need to build a Python from source, make sure you do not use the default ./configure values.  In particular, explicitly set --enable-universalsdk, --with-universal-archs, and MACOSX_DEPLOYMENT_TARGET.  For example,

  ./configure \
      --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk \
      --with-universal-archs=intel \
      --enable-framework \
      MACOSX_DEPLOYMENT_TARGET=10.6

and any other options you might want like:
     --prefix=/path/to/bin
     --enable-framework=/path/to/framework
     --with-framework-name=whatever
         #which also influences the /Applications directory name

And, yes, longer term, we should do provide more appropriate defaults for these newer environments.  As we don't have a lot of experience yet with Xcode 4 and 10.7 has not been released yet, feedback is appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sun May 29 02:41:34 2011
From: report at bugs.python.org (Joesph)
Date: Sun, 29 May 2011 00:41:34 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>
Message-ID: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>


New submission from Joesph <someone3x7 at gmail.com>:

#Example:
class a(object):
    pass

b = a()

print([isinstance(a,object), isinstance(b,object)])

'''
outputs: [True, True]
expected: [False, True]

As class a is not instantiated it should return false. As-is isinstance is just a synonym for issubclass.
'''

----------
components: Interpreter Core
messages: 137160
nosy: someone3x7
priority: normal
severity: normal
status: open
title: isinstance not functioning as documented
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________

From report at bugs.python.org  Sun May 29 02:44:16 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 29 May 2011 00:44:16 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>
Message-ID: <1306629856.33.0.923647315906.issue12203@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

I don't see why this is incorrect, type(a) -> type, and object is a superclass of type.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________

From report at bugs.python.org  Sun May 29 03:19:01 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 May 2011 01:19:01 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>
Message-ID: <1306631941.06.0.285250029675.issue12203@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Everything is an instance of object.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________

From report at bugs.python.org  Sun May 29 03:44:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 May 2011 01:44:41 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306633481.21.0.985439396062.issue12185@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In this case using:
   d.copy_sign(other)
and then refer to 'd' and 'other' might be clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sun May 29 03:54:35 2011
From: report at bugs.python.org (library.engine)
Date: Sun, 29 May 2011 01:54:35 +0000
Subject: [issue8583] Hardcoded namespace_separator in the
	cElementTree.XMLParser
In-Reply-To: <1272668249.2.0.865128956478.issue8583@psf.upfronthosting.co.za>
Message-ID: <1306634075.92.0.724231303082.issue8583@psf.upfronthosting.co.za>


library.engine <library.engine at gmail.com> added the comment:

What is so implicit in the passing of a list of undesired namespaces to the parse function?
This is quite explicit, in my humble opinion, and it lets you not to repeat yourself for each and every tag you want to find in the tree, as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8583>
_______________________________________

From report at bugs.python.org  Sun May 29 04:01:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 May 2011 02:01:01 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306634461.46.0.478749165188.issue12162@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The regex sets (\d\w\s\D\W\S) don't match any Python escape sequence, so even if some suggest to always use r'' regardless, I don't find it necessary, especially for simple regexs.
The two conflicting escape sequences to keep in mind are \b (backspace for Python, word boundary for re) and \number (octal escape for Python, reference to a group for re).
There are also other regex escape sequences that are rarely used (\B\A\Z), but these don't need to be escaped either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12162>
_______________________________________

From report at bugs.python.org  Sun May 29 04:07:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 May 2011 02:07:34 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1306634854.34.0.407245781647.issue12134@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The name dump and dumps exist to match the same API provided by pickle and marshal.

I agree that a note marked as CPython implementation detail should be added.

----------
keywords: +easy -patch
stage:  -> needs patch
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sun May 29 04:13:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 May 2011 02:13:13 +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: <1306635193.08.0.963690741651.issue11975@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +georg.brandl
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Sun May 29 06:49:20 2011
From: report at bugs.python.org (py.user)
Date: Sun, 29 May 2011 04:49:20 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

specification

1)
str.upper()?

    Return a copy of the string converted to uppercase.

2)
str.isupper()?

    Return true if all cased characters in the string are uppercase and there is at least one cased character, false otherwise. Cased characters are those with general category property being one of ?Lu?, ?Ll?, or ?Lt? and uppercase characters are those with general category property ?Lu?.

>>> '\u1ff3'
'?'
>>> '\u1ff3'.islower()
True
>>> '\u1ff3'.upper()
'?'
>>> '\u1ff3'.upper().isupper()
False
>>>

----------
components: None
messages: 137167
nosy: py.user
priority: normal
severity: normal
status: open
title: str.upper converts to title
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Sun May 29 09:06:37 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 29 May 2011 07:06:37 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306652797.8.0.233388490647.issue11623@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't agree that distutils should autodetect architectures, that can result in silent behavior changes when you built extensions and assume ppc support will get compiled in.

We should probably start to mention the intel only builds more prominently though, that's the one that will be useful to most people at this time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sun May 29 09:20:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 May 2011 07:20:05 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1306653605.52.0.774106384452.issue12134@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please don't add notes of this sort to the docs.

----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sun May 29 09:29:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 May 2011 07:29:51 +0000
Subject: [issue12134] json.dump much slower than dumps
In-Reply-To: <1305985086.83.0.259963774289.issue12134@psf.upfronthosting.co.za>
Message-ID: <1306654191.66.0.562149933235.issue12134@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Are you against the proposed wording or the note itself?

Stating that in CPython json.dump doesn't use the C accelerations is a reasonable thing to do imho.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12134>
_______________________________________

From report at bugs.python.org  Sun May 29 10:05:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 May 2011 08:05:14 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1306656314.88.0.590844584798.issue12204@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

'\u1ff3'.upper() returns '\u1ffc', so we have:
  U+1FF3 (? - GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI)
  U+1FFC (? - GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI)
The first belongs to the Ll (Letter, lowercase) category, whereas the second belongs to the Lt (Letter, titlecase) category.

The entries for these two chars in the UnicodeData.txt[0] files are:
1FF3;GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI;Ll;0;L;03C9 0345;;;;N;;;1FFC;;1FFC
1FFC;GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI;Lt;0;L;03A9 0345;;;;N;;;;1FF3;

U+1FF3 has U+1FFC in both the third last and last field (Simple_Uppercase_Mapping and Simple_Titlecase_Mapping respectively -- see [1]), so .upper() is doing the right thing here.
U+1FFC has U+1FF3 in the second last field (Simple_Lowercase_Mapping), but since it's category is not Lu, but Lt, .isupper() returns False.

The Unicode Standard Annex #44[2] defines the Lt category as:
  Lt  Titlecase_Letter  a digraphic character, with first part uppercase

I'm not sure there's anything to fix here, both function behave as documented, and it might indeed be the case that .upper() returns chars with category Lt, that then return False with .isupper()

[0]: http://unicode.org/Public/UNIDATA/UnicodeData.txt
[1]: http://www.unicode.org/reports/tr44/#UnicodeData.txt
[2]: http://www.unicode.org/reports/tr44/#GC_Values_Table

----------
components: +Interpreter Core, Unicode -None
nosy: +belopolsky, ezio.melotti
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Sun May 29 10:14:51 2011
From: report at bugs.python.org (sorin)
Date: Sun, 29 May 2011 08:14:51 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306656891.27.0.114214459971.issue11623@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Let's try to find a good compromise regarding this. I hope the we all agree that we should not put our personal needs or preferences on the first place, it's important to improve the overall experience for most users.

First, we do not want to fail to build and install a package if you are on specific case (xcode3, xcode4, ...).

I think that most people do not have `ARCHFLAGS` env var defined and they should not even care about it. Compilers are smart enough to pick the right architecture for them (xcode3 will build ppc/i386/x64 and xcode4 i386/x64, and who known maybe next version will include armX).

As for package maintainers and they build machines, they are more likely to be already aware about what they want to distribute. For this reason I consider that they can hack the build environment to meet their distribution needs (whatever env vars they want, blend xcode4 with xcode3,...). 

Still as stated in a previous comment, we do not want publish Universal binaries that will miss PPC architecture, in order to prevent this distutils should throw an warning if ppc architecture is not supported (xcode4).

Also if the ARCHFLAGS is defined and includes PPC, the build is supposed to fail.

Some other considerations: think that "some" people may want to install packages to their OS provided Python and in this case the python that comes with 10.6 doesn't have a PPC arch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sun May 29 11:04:43 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 May 2011 09:04:43 +0000
Subject: [issue12205] test_subprocess fails due to uninstalled test
	subdirectory
In-Reply-To: <1306659882.88.0.462152568023.issue12205@psf.upfronthosting.co.za>
Message-ID: <1306659882.88.0.462152568023.issue12205@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

======================================================================
FAIL: test_wait_when_sigchild_ignored (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_subprocess.py", line 860, in test_wait_when_sigchild_ignored
    " non-zero with this error:\n%s" % stderr)
AssertionError: sigchild_ignore.py exited non-zero with this error:
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: can't open file 'subprocessdata/sigchild_ignore.py': [Errno 2] No such file or directory

The Makefile for 3.2 was fixed but not 3.1 nor 2.7.  Fix follows.

----------
assignee: ned.deily
messages: 137173
nosy: benjamin.peterson, gps, ned.deily
priority: normal
severity: normal
status: open
title: test_subprocess fails due to uninstalled test subdirectory
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12205>
_______________________________________

From report at bugs.python.org  Sun May 29 11:13:31 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 29 May 2011 09:13:31 +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: <1306660411.24.0.0581181139102.issue12191@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I added comments in the code review.

this patch is looking good once the comments are addressed.  thanks for your contribution!

As for talk of support for recursion... thats what os.walk() is for.  it doesn't belong as part of any particular individual function itself.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Sun May 29 11:46:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 09:46:10 +0000
Subject: [issue12205] test_subprocess fails due to uninstalled test
	subdirectory
In-Reply-To: <1306659882.88.0.462152568023.issue12205@psf.upfronthosting.co.za>
Message-ID: <E1QQcZV-0006jL-A0@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 8349094d1fe8 by Ned Deily in branch '2.7':
Issue #12205: Fix test_subprocess failure due to uninstalled test data.
http://hg.python.org/cpython/rev/8349094d1fe8

New changeset bd49031b9488 by Ned Deily in branch '3.1':
Issue #12205: Fix test_subprocess failure due to uninstalled test data.
http://hg.python.org/cpython/rev/bd49031b9488

New changeset 791c64fdc405 by Ned Deily in branch '3.2':
Record null merge of Issue #12205
http://hg.python.org/cpython/rev/791c64fdc405

New changeset e8e8a9dbc3c0 by Ned Deily in branch 'default':
Record null merge of Issue #12205
http://hg.python.org/cpython/rev/e8e8a9dbc3c0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12205>
_______________________________________

From report at bugs.python.org  Sun May 29 11:50:19 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 May 2011 09:50:19 +0000
Subject: [issue12205] test_subprocess fails due to uninstalled test
	subdirectory
In-Reply-To: <1306659882.88.0.462152568023.issue12205@psf.upfronthosting.co.za>
Message-ID: <1306662619.38.0.79535026553.issue12205@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Applied to 2.7 (for 2.7.2) and 3.1 (for 3.1.4).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12205>
_______________________________________

From report at bugs.python.org  Sun May 29 12:39:33 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 May 2011 10:39:33 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306665573.25.0.569295391718.issue11623@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"Compilers are smart enough to pick the right architecture for them (xcode3 will build ppc/i386/x64 and xcode4 i386/x64"

Actually, that's not the case for Python builds.  The architecture selection is based on what the builder of the Python interpreter specified on the ./configure command and/or the defaults programmed into ./configure which look at other settings like deployment target. For extension module builds, Distutils attempts to use compile settings that are compatible with those the interpreter was built with, allowing some values to be influenced by environment variable settings.  In either case, the compiler has no say in the selection.

"Some other considerations: think that "some" people may want to install packages to their OS provided Python and in this case the python that comes with 10.6 doesn't have a PPC arch."

Actually, that's also not the case.  The Apple-supplied Pythons in OS X 10.6 do have a PPC arch; try "file /usr/bin/python2.6" in a shell and you'll see there are three archs.  It will even run on 10.6 in PPC emulation under Rosetta (try "arch -ppc /usr/bin/python2.6"),

But I sense a misconception here.  The python.org project has no say about what Apple does or doesn't do with regard to the system Pythons they supply in OS X. Python is an open-source project and many distributors (like Apple) build and release their own versions of Python. The PSF python.org project also builds and releases our own Windows and OS X binary installers.  But what is shipped with OS X is up to Apple.  For 10.6 the system python2.6 has a number of Apple-developed changes and add-ons.  The fact that Xcode 4 has complicated extension module builds with the system Python 2.6 is an issue to be taken up with Apple; there's nothing we here can do about that other than to suggest some workarounds.  And based on past experience, with the imminent release of 10.7, it's highly unlikely Apple will be making any non-security related changes to their Pythons in 10.6.  We'll have to see what 10.7 brings.  For the system Pythons on 10.6, the choice seems clear: either stick with Xcode 3 or resort to workarounds.

What we can do here is try to make things better for users of the python.org source or binary installers for currently supported versions of Python.  Documenting the tradeoffs of our current installer options is one step towards that.  Hope that makes things clearer!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sun May 29 12:47:00 2011
From: report at bugs.python.org (Martin Ponweiser)
Date: Sun, 29 May 2011 10:47:00 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>


New submission from Martin Ponweiser <m.ponweiser at gmail.com>:

I hope the title is self-explanatory.

----------
assignee: docs at python
components: Documentation
messages: 137178
nosy: docs at python, mponweiser
priority: normal
severity: normal
status: open
title: Documentation Std. Library 15.7.5 "LogRecord objects": Parameters: level(currently wrong) -> levelno (correct)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Sun May 29 12:50:24 2011
From: report at bugs.python.org (sorin)
Date: Sun, 29 May 2011 10:50:24 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306666224.72.0.0145928627678.issue11623@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

You are right about Python from 10.6, it has PPC, but 10.7 doesn't.

bash-3.2$ file /Volumes/107/usr/bin/python2.6
/Volumes/107/usr/bin/python2.6: Mach-O universal binary with 2 architectures
/Volumes/107/usr/bin/python2.6 (for architecture x86_64):	Mach-O 64-bit executable x86_64
/Volumes/107/usr/bin/python2.6 (for architecture i386):	Mach-O executable i386

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sun May 29 12:52:02 2011
From: report at bugs.python.org (sorin)
Date: Sun, 29 May 2011 10:52:02 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306666322.44.0.197330668077.issue11623@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

And in addition to 2.5 and 2.6, 10.7 includes 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Sun May 29 13:56:25 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 29 May 2011 11:56:25 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306656314.88.0.590844584798.issue12204@psf.upfronthosting.co.za>
Message-ID: <4DE23466.5050503@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:
> 
> '\u1ff3'.upper() returns '\u1ffc', so we have:
>   U+1FF3 (? - GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI)
>   U+1FFC (? - GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI)
> The first belongs to the Ll (Letter, lowercase) category, whereas the second belongs to the Lt (Letter, titlecase) category.
> 
> The entries for these two chars in the UnicodeData.txt[0] files are:
> 1FF3;GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI;Ll;0;L;03C9 0345;;;;N;;;1FFC;;1FFC
> 1FFC;GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI;Lt;0;L;03A9 0345;;;;N;;;;1FF3;
> 
> U+1FF3 has U+1FFC in both the third last and last field (Simple_Uppercase_Mapping and Simple_Titlecase_Mapping respectively -- see [1]), so .upper() is doing the right thing here.
> U+1FFC has U+1FF3 in the second last field (Simple_Lowercase_Mapping), but since it's category is not Lu, but Lt, .isupper() returns False.
> 
> The Unicode Standard Annex #44[2] defines the Lt category as:
>   Lt  Titlecase_Letter  a digraphic character, with first part uppercase
> 
> I'm not sure there's anything to fix here, both function behave as documented, and it might indeed be the case that .upper() returns chars with category Lt, that then return False with .isupper()
> 
> [0]: http://unicode.org/Public/UNIDATA/UnicodeData.txt
> [1]: http://www.unicode.org/reports/tr44/#UnicodeData.txt
> [2]: http://www.unicode.org/reports/tr44/#GC_Values_Table

I think there's a misunderstanding here: title cased characters
are ones typically used in titles of a document. They don't
necessarily have to be upper case, though, since some characters
are never used as first letters of a word.

Note that .upper() also does not guarantee to return an upper
case character. It just applies the mapping defined in the
Unicode standard and if there is no such mapping, or Python
does not support the mapping, the method returns the
original character.

The German ? is such a character (U+00DF). It doesn't have
an uppercase mapping in actual use and only received such
a mapping in Unicode 5.1 based on rather controversial
grounds (see http://en.wikipedia.org/wiki/?).

The character is normally mapped to 'SS' when converting it
to upper case or title case. This multi-character mapping
is not supported by Python, so .upper() just returns U+00DF.

I suggest to close this ticket as invalid or to add a note
to the documentation explaining how the mapping is applied
(and when not).

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Sun May 29 14:56:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 May 2011 12:56:05 +0000
Subject: [issue12199] Unify TryExcept and TryFinally
In-Reply-To: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>
Message-ID: <1306673765.19.0.546483976472.issue12199@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12199>
_______________________________________

From report at bugs.python.org  Sun May 29 14:57:01 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sun, 29 May 2011 12:57:01 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306673821.18.0.727494201757.issue12185@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

I propose:

object.copy_sign(other)

    Return a copy of *object* with the sign set to be the same as the sign of *other*.

This format is most familiar to me.  But like Ezio wrote, all other methods referring to first and second operands would need to updated to refer to *object* and *other*, respectively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sun May 29 15:11:29 2011
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 29 May 2011 13:11:29 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1306674689.14.0.270664713577.issue9938@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Updated previous patch with test cases and renamed exit_on_argument_error flag to exit_on_error.

----------
Added file: http://bugs.python.org/file22172/issue9938_with_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Sun May 29 15:43:04 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sun, 29 May 2011 13:43:04 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306676584.54.0.403682370151.issue12185@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

Or rather:

object.copy_sign(other)

    Return a copy of *object* with the sign set to be that of *other*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sun May 29 16:37:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 14:37:17 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <E1QQh77-0000uN-57@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 866d959dea8e by Charles-Fran?ois Natali in branch 'default':
Issue #12196: Add PIPE_MAX_SIZE to test.support, constant larger than the
http://hg.python.org/cpython/rev/866d959dea8e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sun May 29 16:58:04 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Sun, 29 May 2011 14:58:04 +0000
Subject: [issue12185] Decimal documentation lists "first" and "second"
	arguments, should be "self" and "other"
In-Reply-To: <1306411163.06.0.644918639795.issue12185@psf.upfronthosting.co.za>
Message-ID: <1306681084.95.0.299706140584.issue12185@psf.upfronthosting.co.za>


Adam Woodbeck <adam.woodbeck at gmail.com> added the comment:

Sorry guys.  I'm new at this.  After reviewing this thread, Terry's suggestion makes the most sense to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12185>
_______________________________________

From report at bugs.python.org  Sun May 29 18:00:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 16:00:15 +0000
Subject: [issue9223] distutils Command docs linking
In-Reply-To: <1278842118.98.0.447580746047.issue9223@psf.upfronthosting.co.za>
Message-ID: <E1QQiPV-0006I6-OZ@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset db60dee0019b by ?ric Araujo in branch '2.7':
Backport doc improvements for distutils.cmd.Command (#9223).
http://hg.python.org/cpython/rev/db60dee0019b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9223>
_______________________________________

From report at bugs.python.org  Sun May 29 18:00:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 16:00:15 +0000
Subject: [issue9831] test_distutils should honor PYTHONDONTWRITEBYTECODE
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <E1QQiPV-0006I6-ON@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset da7617248935 by ?ric Araujo in branch '2.7':
Fix test_distutils when sys.dont_write_bytecode is true (#9831).
http://hg.python.org/cpython/rev/da7617248935

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sun May 29 18:14:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 16:14:20 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <E1QQid8-00070i-PN@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 74fa7b4b934f by ?ric Araujo in branch 'default':
Port r86353 to packaging (#10359: ?;? after function definition is invalid in ISO C)
http://hg.python.org/cpython/rev/74fa7b4b934f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Sun May 29 18:14:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 16:14:20 +0000
Subject: [issue9831] test_distutils should honor PYTHONDONTWRITEBYTECODE
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <E1QQid8-00070i-Oa@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3d56e559ffc6 by ?ric Araujo in branch '3.1':
Fix test_build_py when sys.dont_write_bytecode is true (#9831).
http://hg.python.org/cpython/rev/3d56e559ffc6

New changeset 1370dc2690a2 by ?ric Araujo in branch '3.2':
Merge doc touch-ups and fixes for #9831 and #9223 from 3.1
http://hg.python.org/cpython/rev/1370dc2690a2

New changeset c5d6a384132d by ?ric Araujo in branch 'default':
Merge touch-ups and fixes for #9831 (+port fix to packaging) and #9223 from 3.2
http://hg.python.org/cpython/rev/c5d6a384132d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sun May 29 18:18:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:18:59 +0000
Subject: [issue9831] test_distutils should honor PYTHONDONTWRITEBYTECODE
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1306685939.49.0.252090741039.issue9831@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Now fixed, thanks for the report.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sun May 29 18:19:45 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 29 May 2011 16:19:45 +0000
Subject: [issue9831] test_distutils should honor PYTHONDONTWRITEBYTECODE
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1306685985.31.0.804585264433.issue9831@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Awesome, thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Sun May 29 18:22:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:22:53 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1306686173.07.0.374398794371.issue10454@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi David, I made this patch to port the improvements you made to 2.7.  The new usage message looks like this:

usage: python compileall.py [-l] [-f] [-q] [-d destdir] [-x regexp] [-i list] [directory|file ...]

arguments: zero or more file and directory names to compile; if no arguments given, 
           defaults to the equivalent of -l sys.path

options:
-l: don't recurse into subdirectories
-f: force rebuild even if timestamps are up-to-date
-q: output only error messages
-d destdir: directory to prepend to file paths for use in compile-time tracebacks and in
            runtime tracebacks in cases where the source file is unavailable
-x regexp: skip files matching the regular expression regexp; the regexp is searched for
           in the full path of each file considered for compilation
-i file: add all the files and directories listed in file to the list considered for
         compilation; if "-", names are read from stdin

I noticed some minor style issues, so I (IMO) improved them in my 2.7 patch and made a 3.x patch with the same minor touch-ups.

----------
Added file: http://bugs.python.org/file22173/compileall-help-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Sun May 29 18:23:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:23:13 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1306686193.69.0.797660470634.issue10454@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22174/compileall-help-3.x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Sun May 29 18:31:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:31:20 +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: <1306686680.59.0.700930025134.issue12191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The python-dev discussion talked about chowntree vs. os.walk:
http://mail.python.org/pipermail/python-dev/2011-May/111667.html
http://mail.python.org/pipermail/python-dev/2011-May/111673.html
http://mail.python.org/pipermail/python-dev/2011-May/111674.html

I find those arguments of convenience and precedent convincing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Sun May 29 18:36:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2011 16:36:53 +0000
Subject: [issue12162] Documentation about re \number
In-Reply-To: <1306195657.59.0.977782679394.issue12162@psf.upfronthosting.co.za>
Message-ID: <1306687013.42.0.792033249986.issue12162@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The fact that you have carefully think about which are escapes and which aren't tells you that you should not be depending on the non-escapes not being escapes.  What if we added one?  The doc says preserving the \s is a debugging aid, and that is all it should be used for, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12162>
_______________________________________

From report at bugs.python.org  Sun May 29 18:41:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:41:36 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306687296.37.0.113097809202.issue1625@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If you?re logged into Roundup, you should automatically be logged into our Rietveld instance.  You can file a bug on the meta-tracker (link in the left sidebar) if this does not work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sun May 29 18:42:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:42:59 +0000
Subject: [issue12101] PEPs should have consecutive revision numbers
In-Reply-To: <1305695537.09.0.834655351659.issue12101@psf.upfronthosting.co.za>
Message-ID: <1306687379.46.0.768217160687.issue12101@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This request is not feasible with Mercurial and the useful info is already available.  Closing.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12101>
_______________________________________

From report at bugs.python.org  Sun May 29 18:43:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 16:43:20 +0000
Subject: [issue12199] Unify TryExcept and TryFinally
In-Reply-To: <1306526123.74.0.0902853865806.issue12199@psf.upfronthosting.co.za>
Message-ID: <E1QQj5D-0000UD-0w@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset e0e663132363 by Benjamin Peterson in branch 'default':
unify TryExcept and TryFinally (closes #12199)
http://hg.python.org/cpython/rev/e0e663132363

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12199>
_______________________________________

From report at bugs.python.org  Sun May 29 18:44:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2011 16:44:08 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <1306687448.03.0.458835561998.issue12206@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Sun May 29 18:46:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:46:17 +0000
Subject: [issue12148] Clarify "or-ing together" doctest option flags
In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>
Message-ID: <1306687577.88.0.151782237593.issue12148@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I found ?bitwise OR-ed? in library/fcntl.rst library/functions.rst library/os.rst library/winsound.rst (using grep, not Sphinx :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12148>
_______________________________________

From report at bugs.python.org  Sun May 29 18:48:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 16:48:51 +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: <1306687731.11.0.628009216966.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Again, changing the role :func: to :class: adds zero value to the tools or the human readers.  What?s needed are class *directives* that will provide a target for those links, e.g.:

.. class:: list

   .. method:: append

Then :func:`list` and :meth:`list.append` would generate links to his part of the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Sun May 29 19:21:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:21:41 +0000
Subject: [issue5043] get_msvcr() returns None rather than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1306689701.57.0.0316506044794.issue5043@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for explaining.

> a) NoneType object is not iterable. If the function don't return empty list
> later distutil will fail

Possible fix: self.dll_libraries = get_msvcr() or []

> method for detection of a msvc runtime is not correct. If the method
> return a library GCC will link to two c-runtimes. Also some function
> dearation are not visible if is not specified appropriate
> preprocessor directive.

Can you propose fixes for those?  Also, how to test it?

> So I could not found reason this method to exist .

?Include the appropriate MSVC runtime library if Python was built with MSVC 7.0 or later.?

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5043>
_______________________________________

From report at bugs.python.org  Sun May 29 19:23:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:23:50 +0000
Subject: [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Title says it all.

----------
assignee: docs at python
components: Documentation
files: document-pycf-only-ast.diff
keywords: needs review, patch
messages: 137203
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Document ast.PyCF_ONLY_AST
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22175/document-pycf-only-ast.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12207>
_______________________________________

From report at bugs.python.org  Sun May 29 19:25:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:25:45 +0000
Subject: [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found a bug in email.policy.rst (Msg instead of msg) and did other touch-ups in the file.  Please review.

----------
assignee: docs at python
components: Documentation
files: email.policy-markup-glitches.diff
keywords: patch
messages: 137204
nosy: docs at python, eric.araujo, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Glitches in email.policy docs
versions: Python 3.3
Added file: http://bugs.python.org/file22176/email.policy-markup-glitches.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12208>
_______________________________________

From report at bugs.python.org  Sun May 29 19:29:11 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 May 2011 17:29:11 +0000
Subject: [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1306690151.67.0.770238388892.issue12207@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Use of PyCF_ONLY_AST be superseded by ast.parse.

----------
nosy: +benjamin.peterson
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12207>
_______________________________________

From report at bugs.python.org  Sun May 29 19:30:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:30:03 +0000
Subject: [issue12209] Minor edits to faulthandler doc
In-Reply-To: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>
Message-ID: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I made some grammar fixes in faulthandler.rst and tweaked the example to better show what the module does.

I?d like to fix the synopsis too: ?dump the Python traceback? is not very clear to me.  It is the traceback or the stack trace?  Why is it called ?the? traceback?  Something like ?dumping the stack trace on CPython crashes? would be better IMO.

----------
assignee: docs at python
components: Documentation
files: faulthandler-doc.diff
keywords: needs review, patch
messages: 137206
nosy: docs at python, eric.araujo, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Minor edits to faulthandler doc
versions: Python 3.3
Added file: http://bugs.python.org/file22177/faulthandler-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12209>
_______________________________________

From report at bugs.python.org  Sun May 29 19:31:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:31:22 +0000
Subject: [issue11964] Undocumented change to indent param of json.dump in 3.2
In-Reply-To: <1304178435.78.0.522459822796.issue11964@psf.upfronthosting.co.za>
Message-ID: <1306690282.06.0.626249641954.issue11964@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is my current patch, FYI.

----------
keywords: +patch
Added file: http://bugs.python.org/file22178/versionadded-3.2-json-indent-str.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11964>
_______________________________________

From report at bugs.python.org  Sun May 29 19:31:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:31:52 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1306690312.5.0.95783170133.issue5729@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #11964 for a documentation problem with this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________

From report at bugs.python.org  Sun May 29 19:34:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:34:51 +0000
Subject: [issue968063] Add fileinput.islastline()
Message-ID: <1306690491.04.0.969550941632.issue968063@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would storing len(self._buffer) in the instance be premature optimization?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue968063>
_______________________________________

From report at bugs.python.org  Sun May 29 19:36:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 29 May 2011 17:36:05 +0000
Subject: [issue11751] Increase distutils.filelist test coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1306690565.65.0.361555570596.issue11751@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11751>
_______________________________________

From report at bugs.python.org  Sun May 29 20:08:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 18:08:09 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <E1QQkPI-00069z-1f@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 293c398cd4cf by Charles-Fran?ois Natali in branch 'default':
Issue #12196: Add pipe2() to the os module.
http://hg.python.org/cpython/rev/293c398cd4cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sun May 29 20:12:48 2011
From: report at bugs.python.org (Marc Sibson)
Date: Sun, 29 May 2011 18:12:48 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1306692768.22.0.135452399679.issue10772@psf.upfronthosting.co.za>


Marc Sibson <sibson at gmail.com> added the comment:

issue10772.patch: add help, count and parsers to Doc/library/argparse.rst

----------
keywords: +patch
nosy: +marcs
Added file: http://bugs.python.org/file22179/issue10772.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Sun May 29 20:49:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 May 2011 18:49:30 +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: <1306694970.34.0.00188795839213.issue11254@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Should this be a release blocker for 3.2.1?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sun May 29 20:53:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 29 May 2011 18:53:00 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306695180.87.0.816522980689.issue12196@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The Gentoo buildbot on which O_CLOEXEC test failed also chokes on test_pipe2:

[ 10/355] test_posix
test test_posix failed -- Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_posix.py", line 487, in test_pipe2
    r, w = os.pipe2()
OSError: [Errno 38] Function not implemented

If've added a test to skip this test on Linux kernels older than 2.6.27: like O_CLOEXEC, the problem is that the libc defines pipe2() while the kernel doesn't support it, so when syscall() is called it bails out with ENOSYS.
(This buildbot should really have its libc/kernel upgraded...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sun May 29 21:01:31 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 29 May 2011 19:01: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: <1306695691.44.0.536476012935.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Linking a class using a function directive is counter-intuitive. That's why we need to make use of class directives rather than function directives here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Sun May 29 21:06:07 2011
From: report at bugs.python.org (David Barnett)
Date: Sun, 29 May 2011 19:06:07 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1306695967.33.0.0493909975983.issue11240@psf.upfronthosting.co.za>


Changes by David Barnett <davidbarnett2 at gmail.com>:


----------
nosy: +mu_mind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Sun May 29 21:17:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2011 19:17:38 +0000
Subject: [issue12148] Clarify "or-ing together" doctest option flags
In-Reply-To: <1306058966.52.0.456848115548.issue12148@psf.upfronthosting.co.za>
Message-ID: <1306696658.88.0.52496966231.issue12148@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I like bitwise-or better than bitwise OR because 'bitwise-or' is a distinct operation from 'or', and making it hyphenated emphasizes that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12148>
_______________________________________

From report at bugs.python.org  Sun May 29 22:29:38 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 May 2011 20:29:38 +0000
Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD
In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>
Message-ID: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

With Python 2.7, the FreeBSD AMD64 bot has sporadic failures in
test_smtplib. Since these failures don't occur in other branches,
I wonder if the timeout of 3 seconds is too low in 2.7. The timeout
is 15 seconds in 3.3.


test test_smtplib failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/test/test_smtplib.py", line 186, in testNOOP
    smtp = smtplib.SMTP(HOST, self.port, local_hostname='localhost', timeout=3)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 242, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 303, in connect
    (code, msg) = self.getreply()
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 352, in getreply
    raise SMTPServerDisconnected("Connection unexpectedly closed")
SMTPServerDisconnected: Connection unexpectedly closed

--------------------------------------------------------------------

test test_smtplib failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/test/test_smtplib.py", line 206, in testVRFY
    smtp = smtplib.SMTP(HOST, self.port, local_hostname='localhost', timeout=3)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 242, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 303, in connect
    (code, msg) = self.getreply()
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/smtplib.py", line 352, in getreply
    raise SMTPServerDisconnected("Connection unexpectedly closed")
SMTPServerDisconnected: Connection unexpectedly closed

----------
components: Tests
keywords: buildbot
messages: 137217
nosy: r.david.murray, skrah
priority: normal
severity: normal
status: open
title: test_smtplib: intermittent failures on FreeBSD
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12210>
_______________________________________

From report at bugs.python.org  Sun May 29 22:57:47 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Sun, 29 May 2011 20:57:47 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306702667.87.0.47335668109.issue11416@psf.upfronthosting.co.za>


Changes by Jean-Marc Saffroy <saffroy at gmail.com>:


Removed file: http://bugs.python.org/file21443/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Sun May 29 22:58:18 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Sun, 29 May 2011 20:58:18 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306702698.16.0.486409873288.issue11416@psf.upfronthosting.co.za>


Jean-Marc Saffroy <saffroy at gmail.com> added the comment:

Ping? A patch is available for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Sun May 29 23:01:00 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 May 2011 21:01:00 +0000
Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD
In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>
Message-ID: <1306702860.15.0.276447507795.issue12210@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Indeed, increasing the timeout to 15 solves the problem (I ran the
test with the -F option for about 100 times).

Since the timeout has been increased before to deal with flaky tests
(52682bd738a7), I guess it's ok to do the same for 2.7.

----------
keywords: +patch
Added file: http://bugs.python.org/file22181/issue12210.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12210>
_______________________________________

From report at bugs.python.org  Sun May 29 23:03:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 29 May 2011 21:03:03 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306702983.79.0.479700091049.issue12196@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test now runs fine on the buildbots, closing.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Sun May 29 23:10:05 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 29 May 2011 21:10:05 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306703405.67.0.215681108168.issue11416@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
keywords: +needs review
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Sun May 29 23:17:30 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 May 2011 21:17:30 +0000
Subject: [issue12210] test_smtplib: intermittent failures on FreeBSD
In-Reply-To: <1306700978.51.0.107374125859.issue12210@psf.upfronthosting.co.za>
Message-ID: <1306703850.79.0.589491061467.issue12210@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hmm, testVRFY occurs twice, once with timeout=15 and once with
timeout=3. So there might be another reason why the test passes on
3.3 but not on 2.7.

Anyway, increasing the timeout to 15 throughout does solve
(or suppress) the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12210>
_______________________________________

From report at bugs.python.org  Sun May 29 21:40:25 2011
From: report at bugs.python.org (David Watson)
Date: Sun, 29 May 2011 19:40:25 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1306215836.75.0.300504831736.issue6560@psf.upfronthosting.co.za>
Message-ID: <20110529193953.GA12377@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

On Tue 24 May 2011, Brian May wrote:
> Are there any problems applying the v5 version of the patch to 3.3?

Well, it still works for me, apart from a trivial patch conflict:
I'm attaching a fresh diff (with no changes) against a recent hg
revision.

Antoine did previously question the necessity of all the various
"abstract" mixin classes I used to form unit test fixtures for
different socket types, but the most recent version does, for
instance, use UDPTestBase and TCPTestBase both with and without
the threading and connection-establishing mixins, respectively
(and the replace-existing-classes patch can still be applied to
remove the redundancy with SocketTCPTest, etc.).

Apart from that, I don't know.  Perhaps a review by someone
familiar with the interface would help?

> Also is there any remote chance for a backport to 2.7?

I'd be happy to do one, but I'm pretty sure python.org's 2.x line
is closed to new features.  Perhaps some fork of CPython might be
willing to accept it, though - I don't know.

----------
Added file: http://bugs.python.org/file22180/baikie-hwundram-v5-hg.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________
-------------- next part --------------
# HG changeset patch
# User David Watson <vcs at dbwatson.ukfsn.org>, Heiko Wundram
# Date 1306697321 -3600
# Node ID db275c8b8180743edaa214b6047392764e6e9e67
# Parent  76e9c3e876d461e8ad4a07fcfa39fc23f627877b
Issue #6560: support sendmsg() and recvmsg() on sockets.
Patch by David Watson and Heiko Wundram.

diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
--- a/Doc/library/socket.rst
+++ b/Doc/library/socket.rst
@@ -198,6 +198,7 @@ The module :mod:`socket` exports the fol
           SOMAXCONN
           MSG_*
           SOL_*
+          SCM_*
           IPPROTO_*
           IPPORT_*
           INADDR_*
@@ -511,6 +512,43 @@ The module :mod:`socket` exports the fol
    Availability: Unix (maybe not all platforms).
 
 
+.. function:: CMSG_LEN(length)
+
+   Return the total length, without trailing padding, of an ancillary
+   data item with associated data of the given *length*.  This value
+   can often be used as the buffer size for :meth:`~socket.recvmsg` to
+   receive a single item of ancillary data, but :rfc:`3542` requires
+   portable applications to use :func:`CMSG_SPACE` and thus include
+   space for padding, even when the item will be the last in the
+   buffer.  Raises :exc:`OverflowError` if *length* is outside the
+   permissible range of values.
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
+.. function:: CMSG_SPACE(length)
+
+   Return the buffer size needed for :meth:`~socket.recvmsg` to
+   receive an ancillary data item with associated data of the given
+   *length*, along with any trailing padding.  The buffer space needed
+   to receive multiple items is the sum of the :func:`CMSG_SPACE`
+   values for their associated data lengths.  Raises
+   :exc:`OverflowError` if *length* is outside the permissible range
+   of values.
+
+   Note that some systems might support ancillary data without
+   providing this function.  Also note that setting the buffer size
+   using the results of this function may not precisely limit the
+   amount of ancillary data that can be received, since additional
+   data may be able to fit into the padding area.
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
 .. function:: getdefaulttimeout()
 
    Return the default timeout in floating seconds for new socket objects. A value
@@ -742,6 +780,109 @@ correspond to Unix system calls applicab
    to zero. (The format of *address* depends on the address family --- see above.)
 
 
+.. method:: socket.recvmsg(bufsize[, ancbufsize[, flags]])
+
+   Receive normal data (up to *bufsize* bytes) and ancillary data from
+   the socket.  The *ancbufsize* argument sets the size in bytes of
+   the internal buffer used to receive the ancillary data; it defaults
+   to 0, meaning that no ancillary data will be received.  Appropriate
+   buffer sizes for ancillary data can be calculated using
+   :func:`CMSG_SPACE` or :func:`CMSG_LEN`, and items which do not fit
+   into the buffer might be truncated or discarded.  The *flags*
+   argument defaults to 0 and has the same meaning as for
+   :meth:`recv`.
+
+   The return value is a 4-tuple: ``(data, ancdata, msg_flags,
+   address)``.  The *data* item is a :class:`bytes` object holding the
+   non-ancillary data received.  The *ancdata* item is a list of zero
+   or more tuples ``(cmsg_level, cmsg_type, cmsg_data)`` representing
+   the ancillary data (control messages) received: *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   :class:`bytes` object holding the associated data.  The *msg_flags*
+   item is the bitwise OR of various flags indicating conditions on
+   the received message; see your system documentation for details.
+   If the receiving socket is unconnected, *address* is the address of
+   the sending socket, if available; otherwise, its value is
+   unspecified.
+
+   On some systems, :meth:`sendmsg` and :meth:`recvmsg` can be used to
+   pass file descriptors between processes over an :const:`AF_UNIX`
+   socket.  When this facility is used (it is often restricted to
+   :const:`SOCK_STREAM` sockets), :meth:`recvmsg` will return, in its
+   ancillary data, items of the form ``(socket.SOL_SOCKET,
+   socket.SCM_RIGHTS, fds)``, where *fds* is a :class:`bytes` object
+   representing the new file descriptors as a binary array of the
+   native C :ctype:`int` type.  If :meth:`recvmsg` raises an exception
+   after the system call returns, it will first attempt to close any
+   file descriptors received via this mechanism.
+
+   Some systems do not indicate the truncated length of ancillary data
+   items which have been only partially received.  If an item appears
+   to extend beyond the end of the buffer, :meth:`recvmsg` will issue
+   a :exc:`RuntimeWarning`, and will return the part of it which is
+   inside the buffer provided it has not been truncated before the
+   start of its associated data.
+
+   On systems which support the :const:`SCM_RIGHTS` mechanism, the
+   following function will receive up to *maxfds* file descriptors,
+   returning the message data and a list containing the descriptors
+   (while ignoring unexpected conditions such as unrelated control
+   messages being received).  See also :meth:`sendmsg`. ::
+
+      import socket, array
+
+      def recv_fds(sock, msglen, maxfds):
+          fds = array.array("i")   # Array of ints
+          msg, ancdata, flags, addr = sock.recvmsg(msglen, socket.CMSG_LEN(maxfds * fds.itemsize))
+          for cmsg_level, cmsg_type, cmsg_data in ancdata:
+              if (cmsg_level == socket.SOL_SOCKET and cmsg_type == socket.SCM_RIGHTS):
+                  # Append data, ignoring any truncated integers at the end.
+                  fds.fromstring(cmsg_data[:len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+          return msg, list(fds)
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
+.. method:: socket.recvmsg_into(buffers[, ancbufsize[, flags]])
+
+   Receive normal data and ancillary data from the socket, behaving as
+   :meth:`recvmsg` would, but scatter the non-ancillary data into a
+   series of buffers instead of returning a new bytes object.  The
+   *buffers* argument must be an iterable of objects that export
+   writable buffers (e.g. :class:`bytearray` objects); these will be
+   filled with successive chunks of the non-ancillary data until it
+   has all been written or there are no more buffers.  The operating
+   system may set a limit (:func:`~os.sysconf` value ``SC_IOV_MAX``)
+   on the number of buffers that can be used.  The *ancbufsize* and
+   *flags* arguments have the same meaning as for :meth:`recvmsg`.
+
+   The return value is a 4-tuple: ``(nbytes, ancdata, msg_flags,
+   address)``, where *nbytes* is the total number of bytes of
+   non-ancillary data written into the buffers, and *ancdata*,
+   *msg_flags* and *address* are the same as for :meth:`recvmsg`.
+
+   Example::
+
+      >>> import socket
+      >>> s1, s2 = socket.socketpair()
+      >>> b1 = bytearray(b'----')
+      >>> b2 = bytearray(b'0123456789')
+      >>> b3 = bytearray(b'--------------')
+      >>> s1.send(b'Mary had a little lamb')
+      22
+      >>> s2.recvmsg_into([b1, memoryview(b2)[2:9], b3])
+      (22, [], 0, None)
+      >>> [b1, b2, b3]
+      [bytearray(b'Mary'), bytearray(b'01 had a 9'), bytearray(b'little lamb---')]
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.recvfrom_into(buffer[, nbytes[, flags]])
 
    Receive data from the socket, writing it into *buffer* instead of creating a
@@ -789,6 +930,41 @@ correspond to Unix system calls applicab
    above.)
 
 
+.. method:: socket.sendmsg(buffers[, ancdata[, flags[, address]]])
+
+   Send normal and ancillary data to the socket, gathering the
+   non-ancillary data from a series of buffers and concatenating it
+   into a single message.  The *buffers* argument specifies the
+   non-ancillary data as an iterable of buffer-compatible objects
+   (e.g. :class:`bytes` objects); the operating system may set a limit
+   (:func:`~os.sysconf` value ``SC_IOV_MAX``) on the number of buffers
+   that can be used.  The *ancdata* argument specifies the ancillary
+   data (control messages) as an iterable of zero or more tuples
+   ``(cmsg_level, cmsg_type, cmsg_data)``, where *cmsg_level* and
+   *cmsg_type* are integers specifying the protocol level and
+   protocol-specific type respectively, and *cmsg_data* is a
+   buffer-compatible object holding the associated data.  Note that
+   some systems (in particular, systems without :func:`CMSG_SPACE`)
+   might support sending only one control message per call.  The
+   *flags* argument defaults to 0 and has the same meaning as for
+   :meth:`send`.  If *address* is supplied and not ``None``, it sets a
+   destination address for the message.  The return value is the
+   number of bytes of non-ancillary data sent.
+
+   The following function sends the list of file descriptors *fds*
+   over an :const:`AF_UNIX` socket, on systems which support the
+   :const:`SCM_RIGHTS` mechanism.  See also :meth:`recvmsg`. ::
+
+      import socket, array
+
+      def send_fds(sock, msg, fds):
+          return sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, array.array("i", fds))])
+
+   Availability: most Unix systems.  (XXX: other platforms?)
+
+   .. versionadded:: XXX
+
+
 .. method:: socket.setblocking(flag)
 
    Set blocking or non-blocking mode of the socket: if *flag* is false, the
diff --git a/Lib/ssl.py b/Lib/ssl.py
--- a/Lib/ssl.py
+++ b/Lib/ssl.py
@@ -349,6 +349,14 @@ class SSLSocket(socket):
         else:
             return socket.sendto(self, data, flags_or_addr, addr)
 
+    def sendmsg(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("sendmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.sendmsg(self, *args, **kwargs)
+
     def sendall(self, data, flags=0):
         self._checkClosed()
         if self._sslobj:
@@ -407,6 +415,22 @@ class SSLSocket(socket):
         else:
             return socket.recvfrom_into(self, buffer, nbytes, flags)
 
+    def recvmsg(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("recvmsg not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.recvmsg(self, *args, **kwargs)
+
+    def recvmsg_into(self, *args, **kwargs):
+        self._checkClosed()
+        if self._sslobj:
+            raise ValueError("recvmsg_into not allowed on instances of %s" %
+                             self.__class__)
+        else:
+            return socket.recvmsg_into(self, *args, **kwargs)
+
     def pending(self):
         self._checkClosed()
         if self._sslobj:
diff --git a/Lib/test/test_socket.py b/Lib/test/test_socket.py
--- a/Lib/test/test_socket.py
+++ b/Lib/test/test_socket.py
@@ -7,6 +7,8 @@ import errno
 import io
 import socket
 import select
+import tempfile
+import _testcapi
 import time
 import traceback
 import queue
@@ -34,6 +36,9 @@ except ImportError:
     thread = None
     threading = None
 
+# Size in bytes of the int type
+SIZEOF_INT = array.array("i").itemsize
+
 class SocketTCPTest(unittest.TestCase):
 
     def setUp(self):
@@ -55,6 +60,26 @@ class SocketUDPTest(unittest.TestCase):
         self.serv.close()
         self.serv = None
 
+class ThreadSafeCleanupTestCase(unittest.TestCase):
+    """Subclass of unittest.TestCase with thread-safe cleanup methods.
+
+    This subclass protects the addCleanup() and doCleanups() methods
+    with a recursive lock.
+    """
+
+    if threading:
+        def __init__(self, *args, **kwargs):
+            super().__init__(*args, **kwargs)
+            self._cleanup_lock = threading.RLock()
+
+        def addCleanup(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super().addCleanup(*args, **kwargs)
+
+        def doCleanups(self, *args, **kwargs):
+            with self._cleanup_lock:
+                return super().doCleanups(*args, **kwargs)
+
 class ThreadableTest:
     """Threadable Test class
 
@@ -237,6 +262,243 @@ class SocketPairTest(unittest.TestCase, 
         ThreadableTest.clientTearDown(self)
 
 
+# The following classes are used by the sendmsg()/recvmsg() tests.
+# Combining, for instance, ConnectedStreamTestMixin and TCPTestBase
+# gives a drop-in replacement for SocketConnectedTest, but different
+# address families can be used, and the attributes serv_addr and
+# cli_addr will be set to the addresses of the endpoints.
+
+class SocketTestBase(unittest.TestCase):
+    """A base class for socket tests.
+
+    Subclasses must provide methods newSocket() to return a new socket
+    and bindSock(sock) to bind it to an unused address.
+
+    Creates a socket self.serv and sets self.serv_addr to its address.
+    """
+
+    def setUp(self):
+        self.serv = self.newSocket()
+        self.bindServer()
+
+    def bindServer(self):
+        """Bind server socket and set self.serv_addr to its address."""
+        self.bindSock(self.serv)
+        self.serv_addr = self.serv.getsockname()
+
+    def tearDown(self):
+        self.serv.close()
+        self.serv = None
+
+
+class SocketListeningTestMixin(SocketTestBase):
+    """Mixin to listen on the server socket."""
+
+    def setUp(self):
+        super().setUp()
+        self.serv.listen(1)
+
+
+class ThreadedSocketTestMixin(ThreadSafeCleanupTestCase, SocketTestBase,
+                              ThreadableTest):
+    """Mixin to add client socket and allow client/server tests.
+
+    Client socket is self.cli and its address is self.cli_addr.  See
+    ThreadableTest for usage information.
+    """
+
+    def __init__(self, *args, **kwargs):
+        super().__init__(*args, **kwargs)
+        ThreadableTest.__init__(self)
+
+    def clientSetUp(self):
+        self.cli = self.newClientSocket()
+        self.bindClient()
+
+    def newClientSocket(self):
+        """Return a new socket for use as client."""
+        return self.newSocket()
+
+    def bindClient(self):
+        """Bind client socket and set self.cli_addr to its address."""
+        self.bindSock(self.cli)
+        self.cli_addr = self.cli.getsockname()
+
+    def clientTearDown(self):
+        self.cli.close()
+        self.cli = None
+        ThreadableTest.clientTearDown(self)
+
+
+class ConnectedStreamTestMixin(SocketListeningTestMixin,
+                               ThreadedSocketTestMixin):
+    """Mixin to allow client/server stream tests with connected client.
+
+    Server's socket representing connection to client is self.cli_conn
+    and client's connection to server is self.serv_conn.  (Based on
+    SocketConnectedTest.)
+    """
+
+    def setUp(self):
+        super().setUp()
+        # Indicate explicitly we're ready for the client thread to
+        # proceed and then perform the blocking call to accept
+        self.serverExplicitReady()
+        conn, addr = self.serv.accept()
+        self.cli_conn = conn
+
+    def tearDown(self):
+        self.cli_conn.close()
+        self.cli_conn = None
+        super().tearDown()
+
+    def clientSetUp(self):
+        super().clientSetUp()
+        self.cli.connect(self.serv_addr)
+        self.serv_conn = self.cli
+
+    def clientTearDown(self):
+        self.serv_conn.close()
+        self.serv_conn = None
+        super().clientTearDown()
+
+
+class UnixSocketTestBase(SocketTestBase):
+    """Base class for Unix-domain socket tests."""
+
+    # This class is used for file descriptor passing tests, so we
+    # create the sockets in a private directory so that other users
+    # can't send anything that might be problematic for a privileged
+    # user running the tests.
+
+    def setUp(self):
+        self.dir_path = tempfile.mkdtemp()
+        self.addCleanup(os.rmdir, self.dir_path)
+        super().setUp()
+
+    def bindSock(self, sock):
+        path = tempfile.mktemp(dir=self.dir_path)
+        sock.bind(path)
+        self.addCleanup(support.unlink, path)
+
+class UnixStreamBase(UnixSocketTestBase):
+    """Base class for Unix-domain SOCK_STREAM tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
+
+
+class InetTestBase(SocketTestBase):
+    """Base class for IPv4 socket tests."""
+
+    host = HOST
+
+    def setUp(self):
+        super().setUp()
+        self.port = self.serv_addr[1]
+
+    def bindSock(self, sock):
+        support.bind_port(sock, host=self.host)
+
+class TCPTestBase(InetTestBase):
+    """Base class for TCP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM)
+
+class UDPTestBase(InetTestBase):
+    """Base class for UDP-over-IPv4 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
+
+class SCTPStreamBase(InetTestBase):
+    """Base class for SCTP tests in one-to-one (SOCK_STREAM) mode."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET, socket.SOCK_STREAM,
+                             socket.IPPROTO_SCTP)
+
+
+class Inet6TestBase(InetTestBase):
+    """Base class for IPv6 socket tests."""
+
+    # Don't use "localhost" here - it may not have an IPv6 address
+    # assigned to it by default (e.g. in /etc/hosts), and if someone
+    # has assigned it an IPv4-mapped address, then it's unlikely to
+    # work with the full IPv6 API.
+    host = "::1"
+
+class UDP6TestBase(Inet6TestBase):
+    """Base class for UDP-over-IPv6 tests."""
+
+    def newSocket(self):
+        return socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
+
+
+# Test-skipping decorators for use with ThreadableTest.
+
+def skipWithClientIf(condition, reason):
+    """Skip decorated test if condition is true, add client_skip decorator.
+
+    If the decorated object is not a class, sets its attribute
+    "client_skip" to a decorator which will return an empty function
+    if the test is to be skipped, or the original function if it is
+    not.  This can be used to avoid running the client part of a
+    skipped test when using ThreadableTest.
+    """
+    def client_pass(*args, **kwargs):
+        pass
+    def skipdec(obj):
+        retval = unittest.skip(reason)(obj)
+        if not isinstance(obj, type):
+            retval.client_skip = lambda f: client_pass
+        return retval
+    def noskipdec(obj):
+        if not (isinstance(obj, type) or hasattr(obj, "client_skip")):
+            obj.client_skip = lambda f: f
+        return obj
+    return skipdec if condition else noskipdec
+
+
+def requireAttrs(obj, *attributes):
+    """Skip decorated test if obj is missing any of the given attributes.
+
+    Sets client_skip attribute as skipWithClientIf() does.
+    """
+    missing = [name for name in attributes if not hasattr(obj, name)]
+    return skipWithClientIf(
+        missing, "don't have " + ", ".join(name for name in missing))
+
+
+def requireSocket(*args):
+    """Skip decorated test if a socket cannot be created with given arguments.
+
+    When an argument is given as a string, will use the value of that
+    attribute of the socket module, or skip the test if it doesn't
+    exist.  Sets client_skip attribute as skipWithClientIf() does.
+    """
+    err = None
+    missing = [obj for obj in args if
+               isinstance(obj, str) and not hasattr(socket, obj)]
+    if missing:
+        err = "don't have " + ", ".join(name for name in missing)
+    else:
+        callargs = [getattr(socket, obj) if isinstance(obj, str) else obj
+                    for obj in args]
+        try:
+            s = socket.socket(*callargs)
+        except socket.error as e:
+            # XXX: check errno?
+            err = str(e)
+        else:
+            s.close()
+    return skipWithClientIf(
+        err is not None,
+        "can't create socket({0}): {1}".format(
+            ", ".join(str(o) for o in args), err))
+
+
 #######################################################################
 ## Begin Tests
 
@@ -947,6 +1209,1839 @@ class BasicUDPTest(ThreadedUDPSocketTest
     def _testRecvFromNegative(self):
         self.cli.sendto(MSG, 0, (HOST, self.port))
 
+
+# Tests for the sendmsg()/recvmsg() interface.  Where possible, the
+# same test code is used with different families and types of socket
+# (e.g. stream, datagram), and tests using recvmsg() are repeated
+# using recvmsg_into().
+#
+# The generic test classes such as SendmsgTests and
+# RecvmsgGenericTests inherit from SendrecvmsgBase and expect to be
+# supplied with sockets cli_sock and serv_sock representing the
+# client's and the server's end of the connection respectively, and
+# attributes cli_addr and serv_addr holding their (numeric where
+# appropriate) addresses.
+#
+# The final concrete test classes combine these with subclasses of
+# SocketTestBase which set up client and server sockets of a specific
+# type, and with subclasses of SendrecvmsgBase such as
+# SendrecvmsgDgramBase and SendrecvmsgConnectedBase which map these
+# sockets to cli_sock and serv_sock and override the methods and
+# attributes of SendrecvmsgBase to fill in destination addresses if
+# needed when sending, check for specific flags in msg_flags, etc.
+#
+# RecvmsgIntoMixin provides a version of doRecvmsg() implemented using
+# recvmsg_into().
+
+# XXX: like the other datagram (UDP) tests in this module, the code
+# here assumes that datagram delivery on the local machine will be
+# reliable.
+
+class SendrecvmsgBase(ThreadSafeCleanupTestCase):
+    # Base class for sendmsg()/recvmsg() tests.
+
+    # Time in seconds to wait before considering a test failed, or
+    # None for no timeout.  Not all tests actually set a timeout.
+    fail_timeout = 3.0
+
+    def setUp(self):
+        self.misc_event = threading.Event()
+        super().setUp()
+
+    def sendToServer(self, msg):
+        # Send msg to the server.
+        return self.cli_sock.send(msg)
+
+    # Tuple of alternative default arguments for sendmsg() when called
+    # via sendmsgToServer() (e.g. to include a destination address).
+    sendmsg_to_server_defaults = ()
+
+    def sendmsgToServer(self, *args):
+        # Call sendmsg() on self.cli_sock with the given arguments,
+        # filling in any arguments which are not supplied with the
+        # corresponding items of self.sendmsg_to_server_defaults, if
+        # any.
+        return self.cli_sock.sendmsg(
+            *(args + self.sendmsg_to_server_defaults[len(args):]))
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        # Call recvmsg() on sock with given arguments and return its
+        # result.  Should be used for tests which can use either
+        # recvmsg() or recvmsg_into() - RecvmsgIntoMixin overrides
+        # this method with one which emulates it using recvmsg_into(),
+        # thus allowing the same test to be used for both methods.
+        result = sock.recvmsg(bufsize, *args)
+        self.registerRecvmsgResult(result)
+        return result
+
+    def registerRecvmsgResult(self, result):
+        # Called by doRecvmsg() with the return value of recvmsg() or
+        # recvmsg_into().  Can be overridden to arrange cleanup based
+        # on the returned ancillary data, for instance.
+        pass
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Called to compare the received address with the address of
+        # the peer.
+        self.assertEqual(addr1, addr2)
+
+    # Flags that are normally unset in msg_flags
+    msg_flags_common_unset = 0
+    for name in ("MSG_CTRUNC", "MSG_OOB"):
+        msg_flags_common_unset |= getattr(socket, name, 0)
+
+    # Flags that are normally set
+    msg_flags_common_set = 0
+
+    # Flags set when a complete record has been received (e.g. MSG_EOR
+    # for SCTP)
+    msg_flags_eor_indicator = 0
+
+    # Flags set when a complete record has not been received
+    # (e.g. MSG_TRUNC for datagram sockets)
+    msg_flags_non_eor_indicator = 0
+
+    def checkFlags(self, flags, eor=None, checkset=0, checkunset=0, ignore=0):
+        # Method to check the value of msg_flags returned by recvmsg[_into]().
+        #
+        # Checks that all bits in msg_flags_common_set attribute are
+        # set in "flags" and all bits in msg_flags_common_unset are
+        # unset.
+        #
+        # The "eor" argument specifies whether the flags should
+        # indicate that a full record (or datagram) has been received.
+        # If "eor" is None, no checks are done; otherwise, checks
+        # that:
+        #
+        #  * if "eor" is true, all bits in msg_flags_eor_indicator are
+        #    set and all bits in msg_flags_non_eor_indicator are unset
+        #
+        #  * if "eor" is false, all bits in msg_flags_non_eor_indicator
+        #    are set and all bits in msg_flags_eor_indicator are unset
+        #
+        # If "checkset" and/or "checkunset" are supplied, they require
+        # the given bits to be set or unset respectively, overriding
+        # what the attributes require for those bits.
+        #
+        # If any bits are set in "ignore", they will not be checked,
+        # regardless of the other inputs.
+        #
+        # Will raise Exception if the inputs require a bit to be both
+        # set and unset, and it is not ignored.
+
+        defaultset = self.msg_flags_common_set
+        defaultunset = self.msg_flags_common_unset
+
+        if eor:
+            defaultset |= self.msg_flags_eor_indicator
+            defaultunset |= self.msg_flags_non_eor_indicator
+        elif eor is not None:
+            defaultset |= self.msg_flags_non_eor_indicator
+            defaultunset |= self.msg_flags_eor_indicator
+
+        # Function arguments override defaults
+        defaultset &= ~checkunset
+        defaultunset &= ~checkset
+
+        # Merge arguments with remaining defaults, and check for conflicts
+        checkset |= defaultset
+        checkunset |= defaultunset
+        inboth = checkset & checkunset & ~ignore
+        if inboth:
+            raise Exception("contradictory set, unset requirements for flags "
+                            "{0:#x}".format(inboth))
+
+        # Compare with given msg_flags value
+        mask = (checkset | checkunset) & ~ignore
+        self.assertEqual(flags & mask, checkset & mask)
+
+
+class RecvmsgIntoMixin(SendrecvmsgBase):
+    # Mixin to implement doRecvmsg() using recvmsg_into().
+
+    def doRecvmsg(self, sock, bufsize, *args):
+        buf = bytearray(bufsize)
+        result = sock.recvmsg_into([buf], *args)
+        self.registerRecvmsgResult(result)
+        self.assertGreaterEqual(result[0], 0)
+        self.assertLessEqual(result[0], bufsize)
+        return (bytes(buf[:result[0]]),) + result[1:]
+
+
+class SendrecvmsgDgramFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for datagram sockets.
+
+    @property
+    def msg_flags_non_eor_indicator(self):
+        return super().msg_flags_non_eor_indicator | socket.MSG_TRUNC
+
+
+class SendrecvmsgSCTPFlagsBase(SendrecvmsgBase):
+    # Defines flags to be checked in msg_flags for SCTP sockets.
+
+    @property
+    def msg_flags_eor_indicator(self):
+        return super().msg_flags_eor_indicator | socket.MSG_EOR
+
+
+class SendrecvmsgConnectionlessBase(SendrecvmsgBase):
+    # Base class for tests on connectionless-mode sockets.  Users must
+    # supply sockets on attributes cli and serv to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.serv
+
+    @property
+    def cli_sock(self):
+        return self.cli
+
+    @property
+    def sendmsg_to_server_defaults(self):
+        return ([], [], 0, self.serv_addr)
+
+    def sendToServer(self, msg):
+        return self.cli_sock.sendto(msg, self.serv_addr)
+
+
+class SendrecvmsgConnectedBase(SendrecvmsgBase):
+    # Base class for tests on connected sockets.  Users must supply
+    # sockets on attributes serv_conn and cli_conn (representing the
+    # connections *to* the server and the client), to be mapped to
+    # cli_sock and serv_sock respectively.
+
+    @property
+    def serv_sock(self):
+        return self.cli_conn
+
+    @property
+    def cli_sock(self):
+        return self.serv_conn
+
+    def checkRecvmsgAddress(self, addr1, addr2):
+        # Address is currently "unspecified" for a connected socket,
+        # so we don't examine it
+        pass
+
+
+class SendrecvmsgServerTimeoutBase(SendrecvmsgBase):
+    # Base class to set a timeout on server's socket.
+
+    def setUp(self):
+        super().setUp()
+        self.serv_sock.settimeout(self.fail_timeout)
+
+
+class SendmsgTests(SendrecvmsgServerTimeoutBase):
+    # Tests for sendmsg() which can use any socket type and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsg(self):
+        # Send a simple message with sendmsg().
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG]), len(MSG))
+
+    def testSendmsgDataGenerator(self):
+        # Send from buffer obtained from a generator (not a sequence).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgDataGenerator(self):
+        self.assertEqual(self.sendmsgToServer((o for o in [MSG])),
+                         len(MSG))
+
+    def testSendmsgAncillaryGenerator(self):
+        # Gather (empty) ancillary data from a generator.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgAncillaryGenerator(self):
+        self.assertEqual(self.sendmsgToServer([MSG], (o for o in [])),
+                         len(MSG))
+
+    def testSendmsgArray(self):
+        # Send data from an array instead of the usual bytes object.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgArray(self):
+        self.assertEqual(self.sendmsgToServer([array.array("B", MSG)]),
+                         len(MSG))
+
+    def testSendmsgGather(self):
+        # Send message data from more than one buffer (gather write).
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgGather(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+    def testSendmsgBadArgs(self):
+        # Check that sendmsg() rejects invalid arguments.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadArgs(self):
+        self.assertRaises(TypeError, self.cli_sock.sendmsg)
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          b"not in an iterable")
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG, object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], object())
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [], 0, object())
+        self.sendToServer(b"done")
+
+    def testSendmsgBadCmsg(self):
+        # Check that invalid ancillary data items are rejected.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgBadCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [object()])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(object(), 0, b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, object(), b"data")])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, object())])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0)])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b"data", 42)])
+        self.sendToServer(b"done")
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testSendmsgBadMultiCmsg(self):
+        # Check that invalid ancillary data items are rejected when
+        # more than one item is present.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    @testSendmsgBadMultiCmsg.client_skip
+    def _testSendmsgBadMultiCmsg(self):
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [0, 0, b""])
+        self.assertRaises(TypeError, self.sendmsgToServer,
+                          [MSG], [(0, 0, b""), object()])
+        self.sendToServer(b"done")
+
+    def testSendmsgExcessCmsgReject(self):
+        # Check that sendmsg() rejects excess ancillary data items
+        # when the number that can be sent is limited.
+        self.assertEqual(self.serv_sock.recv(1000), b"done")
+
+    def _testSendmsgExcessCmsgReject(self):
+        if not hasattr(socket, "CMSG_SPACE"):
+            # Can only send one item
+            with self.assertRaises(socket.error) as cm:
+                self.sendmsgToServer([MSG], [(0, 0, b""), (0, 0, b"")])
+            self.assertIsNone(cm.exception.errno)
+        self.sendToServer(b"done")
+
+    def testSendmsgAfterClose(self):
+        # Check that sendmsg() fails on a closed socket.
+        pass
+
+    def _testSendmsgAfterClose(self):
+        self.cli_sock.close()
+        self.assertRaises(socket.error, self.sendmsgToServer, [MSG])
+
+
+class SendmsgStreamTests(SendmsgTests):
+    # Tests for sendmsg() which require a stream socket and do not
+    # involve recvmsg() or recvmsg_into().
+
+    def testSendmsgExplicitNoneAddr(self):
+        # Check that peer address can be specified as None.
+        self.assertEqual(self.serv_sock.recv(len(MSG)), MSG)
+
+    def _testSendmsgExplicitNoneAddr(self):
+        self.assertEqual(self.sendmsgToServer([MSG], [], 0, None), len(MSG))
+
+    def testSendmsgTimeout(self):
+        # Check that timeout works with sendmsg().
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    def _testSendmsgTimeout(self):
+        try:
+            self.cli_sock.settimeout(0.03)
+            with self.assertRaises(socket.timeout):
+                while True:
+                    self.sendmsgToServer([b"a"*512])
+        finally:
+            self.misc_event.set()
+
+    # XXX: would be nice to have more tests for sendmsg flags argument.
+
+    # Linux supports MSG_DONTWAIT when sending, but in general, it
+    # only works when receiving.  Could add other platforms if they
+    # support it too.
+    @skipWithClientIf(sys.platform not in {"linux2"},
+                      "MSG_DONTWAIT not known to work on this platform when "
+                      "sending")
+    def testSendmsgDontWait(self):
+        # Check that MSG_DONTWAIT in flags causes non-blocking behaviour.
+        self.assertEqual(self.serv_sock.recv(512), b"a"*512)
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @testSendmsgDontWait.client_skip
+    def _testSendmsgDontWait(self):
+        try:
+            with self.assertRaises(socket.error) as cm:
+                while True:
+                    self.sendmsgToServer([b"a"*512], [], socket.MSG_DONTWAIT)
+            self.assertIn(cm.exception.errno,
+                          (errno.EAGAIN, errno.EWOULDBLOCK))
+        finally:
+            self.misc_event.set()
+
+
+class SendmsgConnectionlessTests(SendmsgTests):
+    # Tests for sendmsg() which require a connectionless-mode
+    # (e.g. datagram) socket, and do not involve recvmsg() or
+    # recvmsg_into().
+
+    def testSendmsgNoDestAddr(self):
+        # Check that sendmsg() fails when no destination address is
+        # given for unconnected socket.
+        pass
+
+    def _testSendmsgNoDestAddr(self):
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG])
+        self.assertRaises(socket.error, self.cli_sock.sendmsg,
+                          [MSG], [], 0, None)
+
+
+class RecvmsgGenericTests(SendrecvmsgBase):
+    # Tests for recvmsg() which can also be emulated using
+    # recvmsg_into(), and can use any socket type.
+
+    def testRecvmsg(self):
+        # Receive a simple message with recvmsg[_into]().
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsg(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgExplicitDefaults(self):
+        # Test recvmsg[_into]() with default arguments provided explicitly.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgExplicitDefaults(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShorter(self):
+        # Receive a message smaller than buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) + 42)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShorter(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgTrunc(self):
+        # Receive part of message, check for truncation indicators.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+    def _testRecvmsgTrunc(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgShortAncillaryBuf(self):
+        # Test ancillary data buffer too small to hold any ancillary data.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 1)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgShortAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgLongAncillaryBuf(self):
+        # Test large ancillary data buffer.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgLongAncillaryBuf(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgAfterClose(self):
+        # Check that recvmsg[_into]() fails on a closed socket.
+        self.serv_sock.close()
+        self.assertRaises(socket.error, self.doRecvmsg, self.serv_sock, 1024)
+
+    def _testRecvmsgAfterClose(self):
+        pass
+
+    def testRecvmsgTimeout(self):
+        # Check that timeout works.
+        try:
+            self.serv_sock.settimeout(0.03)
+            self.assertRaises(socket.timeout,
+                              self.doRecvmsg, self.serv_sock, len(MSG))
+        finally:
+            self.misc_event.set()
+
+    def _testRecvmsgTimeout(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+
+    @requireAttrs(socket, "MSG_PEEK")
+    def testRecvmsgPeek(self):
+        # Check that MSG_PEEK in flags enables examination of pending
+        # data without consuming it.
+
+        # Receive part of data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG) - 3, 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG[:-3])
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        # Ignoring MSG_TRUNC here (so this test is the same for stream
+        # and datagram sockets).  Some wording in POSIX seems to
+        # suggest that it needn't be set when peeking, but that may
+        # just be a slip.
+        self.checkFlags(flags, eor=False,
+                        ignore=getattr(socket, "MSG_TRUNC", 0))
+
+        # Receive all data with MSG_PEEK.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 0,
+                                                   socket.MSG_PEEK)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        # Check that the same data can still be received normally.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgPeek.client_skip
+    def _testRecvmsgPeek(self):
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testRecvmsgFromSendmsg(self):
+        # Test receiving with recvmsg[_into]() when message is sent
+        # using sendmsg().
+        self.serv_sock.settimeout(self.fail_timeout)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, len(MSG))
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    @testRecvmsgFromSendmsg.client_skip
+    def _testRecvmsgFromSendmsg(self):
+        self.assertEqual(self.sendmsgToServer([MSG[:3], MSG[3:]]), len(MSG))
+
+
+class RecvmsgGenericStreamTests(RecvmsgGenericTests):
+    # Tests which require a stream socket and can use either recvmsg()
+    # or recvmsg_into().
+
+    def testRecvmsgEOF(self):
+        # Receive end-of-stream indicator (b"", peer socket closed).
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.assertEqual(msg, b"")
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=None) # Might not have end-of-record marker
+
+    def _testRecvmsgEOF(self):
+        self.cli_sock.close()
+
+    def testRecvmsgOverflow(self):
+        # Receive a message in more than one chunk.
+        seg1, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                    len(MSG) - 3)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=False)
+
+        seg2, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+        msg = seg1 + seg2
+        self.assertEqual(msg, MSG)
+
+    def _testRecvmsgOverflow(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgTests(RecvmsgGenericTests):
+    # Tests for recvmsg() which can use any socket type.
+
+    def testRecvmsgBadArgs(self):
+        # Check that recvmsg() rejects invalid arguments.
+        self.assertRaises(TypeError, self.serv_sock.recvmsg)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          -1, 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg,
+                          len(MSG), -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          [bytearray(10)], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          object(), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg,
+                          len(MSG), 0, object())
+
+        msg, ancdata, flags, addr = self.serv_sock.recvmsg(len(MSG), 0, 0)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgBadArgs(self):
+        self.sendToServer(MSG)
+
+
+class RecvmsgIntoTests(RecvmsgIntoMixin, RecvmsgGenericTests):
+    # Tests for recvmsg_into() which can use any socket type.
+
+    def testRecvmsgIntoBadArgs(self):
+        # Check that recvmsg_into() rejects invalid arguments.
+        buf = bytearray(len(MSG))
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          len(MSG), 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          buf, 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [object()], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [b"I'm not writable"], 0, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf, object()], 0, 0)
+        self.assertRaises(ValueError, self.serv_sock.recvmsg_into,
+                          [buf], -1, 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], object(), 0)
+        self.assertRaises(TypeError, self.serv_sock.recvmsg_into,
+                          [buf], 0, object())
+
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf], 0, 0)
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoBadArgs(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoGenerator(self):
+        # Receive into buffer obtained from a generator (not a sequence).
+        buf = bytearray(len(MSG))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            (o for o in [buf]))
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf, bytearray(MSG))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoGenerator(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoArray(self):
+        # Receive into an array rather than the usual bytearray.
+        buf = array.array("B", bytes(len(MSG)))
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into([buf])
+        self.assertEqual(nbytes, len(MSG))
+        self.assertEqual(buf.tostring(), MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoArray(self):
+        self.sendToServer(MSG)
+
+    def testRecvmsgIntoScatter(self):
+        # Receive into multiple buffers (scatter write).
+        b1 = bytearray(b"----")
+        b2 = bytearray(b"0123456789")
+        b3 = bytearray(b"--------------")
+        nbytes, ancdata, flags, addr = self.serv_sock.recvmsg_into(
+            [b1, memoryview(b2)[2:9], b3])
+        self.assertEqual(nbytes, len(b"Mary had a little lamb"))
+        self.assertEqual(b1, bytearray(b"Mary"))
+        self.assertEqual(b2, bytearray(b"01 had a 9"))
+        self.assertEqual(b3, bytearray(b"little lamb---"))
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True)
+
+    def _testRecvmsgIntoScatter(self):
+        self.sendToServer(b"Mary had a little lamb")
+
+
+class CmsgMacroTests(unittest.TestCase):
+    # Test the functions CMSG_LEN() and CMSG_SPACE().  Tests
+    # assumptions used by sendmsg() and recvmsg[_into](), which share
+    # code with these functions.
+
+    # Match the definition in socketmodule.c
+    socklen_t_limit = min(0x7fffffff, _testcapi.INT_MAX)
+
+    @requireAttrs(socket, "CMSG_LEN")
+    def testCMSG_LEN(self):
+        # Test CMSG_LEN() with various valid and invalid values,
+        # checking the assumptions used by recvmsg() and sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_LEN(0) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(socket.CMSG_LEN(0), array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_LEN(n)
+            # This is how recvmsg() calculates the data size
+            self.assertEqual(ret - socket.CMSG_LEN(0), n)
+            self.assertLessEqual(ret, self.socklen_t_limit)
+
+        self.assertRaises(OverflowError, socket.CMSG_LEN, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_LEN, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_LEN, sys.maxsize)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testCMSG_SPACE(self):
+        # Test CMSG_SPACE() with various valid and invalid values,
+        # checking the assumptions used by sendmsg().
+        toobig = self.socklen_t_limit - socket.CMSG_SPACE(1) + 1
+        values = list(range(257)) + list(range(toobig - 257, toobig))
+
+        last = socket.CMSG_SPACE(0)
+        # struct cmsghdr has at least three members, two of which are ints
+        self.assertGreater(last, array.array("i").itemsize * 2)
+        for n in values:
+            ret = socket.CMSG_SPACE(n)
+            self.assertGreaterEqual(ret, last)
+            self.assertGreaterEqual(ret, socket.CMSG_LEN(n))
+            self.assertGreaterEqual(ret, n + socket.CMSG_LEN(0))
+            self.assertLessEqual(ret, self.socklen_t_limit)
+            last = ret
+
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, -1)
+        # sendmsg() shares code with these functions, and requires
+        # that it reject values over the limit.
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, toobig)
+        self.assertRaises(OverflowError, socket.CMSG_SPACE, sys.maxsize)
+
+
+class SCMRightsTest(SendrecvmsgServerTimeoutBase):
+    # Tests for file descriptor passing on Unix-domain sockets.
+
+    # Invalid file descriptor value that's unlikely to evaluate to a
+    # real FD even if one of its bytes is replaced with a different
+    # value (which shouldn't actually happen).
+    badfd = -0x5555
+
+    def newFDs(self, n):
+        # Return a list of n file descriptors for newly-created files
+        # containing their list indices as ASCII numbers.
+        fds = []
+        for i in range(n):
+            fd, path = tempfile.mkstemp()
+            self.addCleanup(os.unlink, path)
+            self.addCleanup(os.close, fd)
+            os.write(fd, str(i).encode())
+            fds.append(fd)
+        return fds
+
+    def checkFDs(self, fds):
+        # Check that the file descriptors in the given list contain
+        # their correct list indices as ASCII numbers.
+        for n, fd in enumerate(fds):
+            os.lseek(fd, 0, os.SEEK_SET)
+            self.assertEqual(os.read(fd, 1024), str(n).encode())
+
+    def registerRecvmsgResult(self, result):
+        self.addCleanup(self.closeRecvmsgFDs, result)
+
+    def closeRecvmsgFDs(self, recvmsg_result):
+        # Close all file descriptors specified in the ancillary data
+        # of the given return value from recvmsg() or recvmsg_into().
+        for cmsg_level, cmsg_type, cmsg_data in recvmsg_result[1]:
+            if (cmsg_level == socket.SOL_SOCKET and
+                    cmsg_type == socket.SCM_RIGHTS):
+                fds = array.array("i")
+                fds.fromstring(cmsg_data[:
+                        len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+                for fd in fds:
+                    os.close(fd)
+
+    def createAndSendFDs(self, n):
+        # Send n new file descriptors created by newFDs() to the
+        # server, with the constant MSG as the non-ancillary data.
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.SOL_SOCKET,
+                                   socket.SCM_RIGHTS,
+                                   array.array("i", self.newFDs(n)))]),
+            len(MSG))
+
+    def checkRecvmsgFDs(self, numfds, result, maxcmsgs=1, ignoreflags=0):
+        # Check that constant MSG was received with numfds file
+        # descriptors in a maximum of maxcmsgs control messages (which
+        # must contain only complete integers).  By default, check
+        # that MSG_CTRUNC is unset, but ignore any flags in
+        # ignoreflags.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertIsInstance(ancdata, list)
+        self.assertLessEqual(len(ancdata), maxcmsgs)
+        fds = array.array("i")
+        for item in ancdata:
+            self.assertIsInstance(item, tuple)
+            cmsg_level, cmsg_type, cmsg_data = item
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertIsInstance(cmsg_data, bytes)
+            self.assertEqual(len(cmsg_data) % SIZEOF_INT, 0)
+            fds.fromstring(cmsg_data)
+
+        self.assertEqual(len(fds), numfds)
+        self.checkFDs(fds)
+
+    def testFDPassSimple(self):
+        # Pass a single FD (array read from bytes object).
+        self.checkRecvmsgFDs(1, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testFDPassSimple(self):
+        self.assertEqual(
+            self.sendmsgToServer(
+                [MSG],
+                [(socket.SOL_SOCKET,
+                  socket.SCM_RIGHTS,
+                  array.array("i", self.newFDs(1)).tostring())]),
+            len(MSG))
+
+    def testMultipleFDPass(self):
+        # Pass multiple FDs in a single array.
+        self.checkRecvmsgFDs(4, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240))
+
+    def _testMultipleFDPass(self):
+        self.createAndSendFDs(4)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassCMSG_SPACE(self):
+        # Test using CMSG_SPACE() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(
+            4, self.doRecvmsg(self.serv_sock, len(MSG),
+                              socket.CMSG_SPACE(4 * SIZEOF_INT)))
+
+    @testFDPassCMSG_SPACE.client_skip
+    def _testFDPassCMSG_SPACE(self):
+        self.createAndSendFDs(4)
+
+    def testFDPassCMSG_LEN(self):
+        # Test using CMSG_LEN() to calculate ancillary buffer size.
+        self.checkRecvmsgFDs(1,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_LEN(4 * SIZEOF_INT)),
+                             # RFC 3542 says implementations may set
+                             # MSG_CTRUNC if there isn't enough space
+                             # for trailing padding.
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassCMSG_LEN(self):
+        self.createAndSendFDs(1)
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparate(self):
+        # Pass two FDs in two separate arrays.  Arrays may be combined
+        # into a single control message by the OS.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG), 10240),
+                             maxcmsgs=2)
+
+    @testFDPassSeparate.client_skip
+    def _testFDPassSeparate(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassSeparateMinSpace(self):
+        # Pass two FDs in two separate arrays, receiving them into the
+        # minimum space for two arrays.
+        self.checkRecvmsgFDs(2,
+                             self.doRecvmsg(self.serv_sock, len(MSG),
+                                            socket.CMSG_SPACE(SIZEOF_INT) +
+                                            socket.CMSG_LEN(SIZEOF_INT)),
+                             maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
+
+    @testFDPassSeparateMinSpace.client_skip
+    def _testFDPassSeparateMinSpace(self):
+        fd0, fd1 = self.newFDs(2)
+        self.assertEqual(
+            self.sendmsgToServer([MSG], [(socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd0])),
+                                         (socket.SOL_SOCKET,
+                                          socket.SCM_RIGHTS,
+                                          array.array("i", [fd1]))]),
+            len(MSG))
+
+    def sendAncillaryIfPossible(self, msg, ancdata):
+        # Try to send msg and ancdata to server, but if the system
+        # call fails, just send msg with no ancillary data.
+        try:
+            nbytes = self.sendmsgToServer([msg], ancdata)
+        except socket.error as e:
+            # Check that it was the system call that failed
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer([msg])
+        self.assertEqual(nbytes, len(msg))
+
+    def testFDPassEmpty(self):
+        # Try to pass an empty FD array.  Can receive either no array
+        # or an empty array.
+        self.checkRecvmsgFDs(0, self.doRecvmsg(self.serv_sock,
+                                               len(MSG), 10240),
+                             ignoreflags=socket.MSG_CTRUNC)
+
+    def _testFDPassEmpty(self):
+        self.sendAncillaryIfPossible(MSG, [(socket.SOL_SOCKET,
+                                            socket.SCM_RIGHTS,
+                                            b"")])
+
+    def testFDPassPartialInt(self):
+        # Try to pass a truncated FD array.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 1)
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    def _testFDPassPartialInt(self):
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [self.badfd]).tostring()[:-1])])
+
+    @requireAttrs(socket, "CMSG_SPACE")
+    def testFDPassPartialIntInMiddle(self):
+        # Try to pass two FD arrays, the first of which is truncated.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), 10240)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, ignore=socket.MSG_CTRUNC)
+        self.assertLessEqual(len(ancdata), 2)
+        fds = array.array("i")
+        # Arrays may have been combined in a single control message
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+            self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+            fds.fromstring(cmsg_data[:
+                    len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.assertLessEqual(len(fds), 2)
+        self.checkFDs(fds)
+
+    @testFDPassPartialIntInMiddle.client_skip
+    def _testFDPassPartialIntInMiddle(self):
+        fd0, fd1 = self.newFDs(2)
+        self.sendAncillaryIfPossible(
+            MSG,
+            [(socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd0, self.badfd]).tostring()[:-1]),
+             (socket.SOL_SOCKET,
+              socket.SCM_RIGHTS,
+              array.array("i", [fd1]))])
+
+    def checkTruncatedHeader(self, result, ignoreflags=0):
+        # Check that no ancillary data items are returned when data is
+        # truncated inside the cmsghdr structure.
+        msg, ancdata, flags, addr = result
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no buffer size
+        # is specified.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG)),
+                                  # BSD seems to set MSG_CTRUNC only
+                                  # if an item has been partially
+                                  # received.
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTruncNoBufSize(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc0(self):
+        # Check that no ancillary data is received when buffer size is 0.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 0),
+                                  ignoreflags=socket.MSG_CTRUNC)
+
+    def _testCmsgTrunc0(self):
+        self.createAndSendFDs(1)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    def testCmsgTrunc1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG), 1))
+
+    def _testCmsgTrunc1(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTrunc2Int(self):
+        # The cmsghdr structure has at least three members, two of
+        # which are ints, so we still shouldn't see any ancillary
+        # data.
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 SIZEOF_INT * 2))
+
+    def _testCmsgTrunc2Int(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Minus1(self):
+        self.checkTruncatedHeader(self.doRecvmsg(self.serv_sock, len(MSG),
+                                                 socket.CMSG_LEN(0) - 1))
+
+    def _testCmsgTruncLen0Minus1(self):
+        self.createAndSendFDs(1)
+
+    # The following tests try to truncate the control message in the
+    # middle of the FD array.
+
+    def checkTruncatedArray(self, ancbuf, maxdata, mindata=0):
+        # Check that file descriptor data is truncated to between
+        # mindata and maxdata bytes when received with buffer size
+        # ancbuf, and that any complete file descriptor numbers are
+        # valid.
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbuf)
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        if mindata == 0 and ancdata == []:
+            return
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.SOL_SOCKET)
+        self.assertEqual(cmsg_type, socket.SCM_RIGHTS)
+        self.assertGreaterEqual(len(cmsg_data), mindata)
+        self.assertLessEqual(len(cmsg_data), maxdata)
+        fds = array.array("i")
+        fds.fromstring(cmsg_data[:
+                len(cmsg_data) - (len(cmsg_data) % fds.itemsize)])
+        self.checkFDs(fds)
+
+    def testCmsgTruncLen0(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
+
+    def _testCmsgTruncLen0(self):
+        self.createAndSendFDs(1)
+
+    def testCmsgTruncLen0Plus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0) + 1, maxdata=1)
+
+    def _testCmsgTruncLen0Plus1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(SIZEOF_INT),
+                                 maxdata=SIZEOF_INT)
+
+    def _testCmsgTruncLen1(self):
+        self.createAndSendFDs(2)
+
+    def testCmsgTruncLen2Minus1(self):
+        self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(2 * SIZEOF_INT) - 1,
+                                 maxdata=(2 * SIZEOF_INT) - 1)
+
+    def _testCmsgTruncLen2Minus1(self):
+        self.createAndSendFDs(2)
+
+
+class RFC3542AncillaryTest(SendrecvmsgServerTimeoutBase):
+    # Test sendmsg() and recvmsg[_into]() using the ancillary data
+    # features of the RFC 3542 Advanced Sockets API for IPv6.
+    # Currently we can only handle certain data items (e.g. traffic
+    # class, hop limit, MTU discovery and fragmentation settings)
+    # without resorting to unportable means such as the struct module,
+    # but the tests here are aimed at testing the ancillary data
+    # handling in sendmsg() and recvmsg() rather than the IPv6 API
+    # itself.
+
+    # Test value to use when setting hop limit of packet
+    hop_limit = 2
+
+    # Test value to use when setting traffic class of packet.
+    # -1 means "use kernel default".
+    traffic_class = -1
+
+    def ancillaryMapping(self, ancdata):
+        # Given ancillary data list ancdata, return a mapping from
+        # pairs (cmsg_level, cmsg_type) to corresponding cmsg_data.
+        # Check that no (level, type) pair appears more than once.
+        d = {}
+        for cmsg_level, cmsg_type, cmsg_data in ancdata:
+            self.assertNotIn((cmsg_level, cmsg_type), d)
+            d[(cmsg_level, cmsg_type)] = cmsg_data
+        return d
+
+    def checkHopLimit(self, ancbufsize, maxhop=255, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space.  Check that data is MSG, ancillary data is not
+        # truncated (but ignore any flags in ignoreflags), and hop
+        # limit is between 0 and maxhop inclusive.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        self.assertIsInstance(ancdata[0], tuple)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+        self.assertIsInstance(cmsg_data, bytes)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimit(self):
+        # Test receiving the packet hop limit as ancillary data.
+        self.checkHopLimit(ancbufsize=10240)
+
+    @testRecvHopLimit.client_skip
+    def _testRecvHopLimit(self):
+        # Need to wait until server has asked to receive ancillary
+        # data, as implementations are not required to buffer it
+        # otherwise.
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testRecvHopLimitCMSG_SPACE(self):
+        # Test receiving hop limit, using CMSG_SPACE to calculate buffer size.
+        self.checkHopLimit(ancbufsize=socket.CMSG_SPACE(SIZEOF_INT))
+
+    @testRecvHopLimitCMSG_SPACE.client_skip
+    def _testRecvHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Could test receiving into buffer sized using CMSG_LEN, but RFC
+    # 3542 says portable applications must provide space for trailing
+    # padding.  Implementations may set MSG_CTRUNC if there isn't
+    # enough space for the padding.
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSetHopLimit(self):
+        # Test setting hop limit on outgoing packet and receiving it
+        # at the other end.
+        self.checkHopLimit(ancbufsize=10240, maxhop=self.hop_limit)
+
+    @testSetHopLimit.client_skip
+    def _testSetHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    def checkTrafficClassAndHopLimit(self, ancbufsize, maxhop=255,
+                                     ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space.  Check that data is MSG, ancillary
+        # data is not truncated (but ignore any flags in ignoreflags),
+        # and traffic class and hop limit are in range (hop limit no
+        # more than maxhop).
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkunset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+        self.assertEqual(len(ancdata), 2)
+        ancmap = self.ancillaryMapping(ancdata)
+
+        tcdata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_TCLASS)]
+        self.assertEqual(len(tcdata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(tcdata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        hldata = ancmap[(socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT)]
+        self.assertEqual(len(hldata), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(hldata)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], maxhop)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimit(self):
+        # Test receiving traffic class and hop limit as ancillary data.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240)
+
+    @testRecvTrafficClassAndHopLimit.client_skip
+    def _testRecvTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        # Test receiving traffic class and hop limit, using
+        # CMSG_SPACE() to calculate buffer size.
+        self.checkTrafficClassAndHopLimit(
+            ancbufsize=socket.CMSG_SPACE(SIZEOF_INT) * 2)
+
+    @testRecvTrafficClassAndHopLimitCMSG_SPACE.client_skip
+    def _testRecvTrafficClassAndHopLimitCMSG_SPACE(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSetTrafficClassAndHopLimit(self):
+        # Test setting traffic class and hop limit on outgoing packet,
+        # and receiving them at the other end.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testSetTrafficClassAndHopLimit.client_skip
+    def _testSetTrafficClassAndHopLimit(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.assertEqual(
+            self.sendmsgToServer([MSG],
+                                 [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                                   array.array("i", [self.traffic_class])),
+                                  (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                                   array.array("i", [self.hop_limit]))]),
+            len(MSG))
+
+    @requireAttrs(socket.socket, "sendmsg")
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testOddCmsgSize(self):
+        # Try to send ancillary data with first item one byte too
+        # long.  Fall back to sending with correct size if this fails,
+        # and check that second item was handled correctly.
+        self.checkTrafficClassAndHopLimit(ancbufsize=10240,
+                                          maxhop=self.hop_limit)
+
+    @testOddCmsgSize.client_skip
+    def _testOddCmsgSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        try:
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class]).tostring() + b"\x00"),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+        except socket.error as e:
+            self.assertIsInstance(e.errno, int)
+            nbytes = self.sendmsgToServer(
+                [MSG],
+                [(socket.IPPROTO_IPV6, socket.IPV6_TCLASS,
+                  array.array("i", [self.traffic_class])),
+                 (socket.IPPROTO_IPV6, socket.IPV6_HOPLIMIT,
+                  array.array("i", [self.hop_limit]))])
+            self.assertEqual(nbytes, len(MSG))
+
+    # Tests for proper handling of truncated ancillary data
+
+    def checkHopLimitTruncatedHeader(self, ancbufsize, ignoreflags=0):
+        # Receive hop limit into ancbufsize bytes of ancillary data
+        # space, which should be too small to contain the ancillary
+        # data header (if ancbufsize is None, pass no second argument
+        # to recvmsg()).  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and no ancillary data is
+        # returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        args = () if ancbufsize is None else (ancbufsize,)
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), *args)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.assertEqual(ancdata, [])
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testCmsgTruncNoBufSize(self):
+        # Check that no ancillary data is received when no ancillary
+        # buffer size is provided.
+        self.checkHopLimitTruncatedHeader(ancbufsize=None,
+                                          # BSD seems to set
+                                          # MSG_CTRUNC only if an item
+                                          # has been partially
+                                          # received.
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testCmsgTruncNoBufSize.client_skip
+    def _testCmsgTruncNoBufSize(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc0(self):
+        # Check that no ancillary data is received when ancillary
+        # buffer size is zero.
+        self.checkHopLimitTruncatedHeader(ancbufsize=0,
+                                          ignoreflags=socket.MSG_CTRUNC)
+
+    @testSingleCmsgTrunc0.client_skip
+    def _testSingleCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    # Check that no ancillary data is returned for various non-zero
+    # (but still too small) buffer sizes.
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=1)
+
+    @testSingleCmsgTrunc1.client_skip
+    def _testSingleCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTrunc2Int(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=2 * SIZEOF_INT)
+
+    @testSingleCmsgTrunc2Int.client_skip
+    def _testSingleCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncLen0Minus1(self):
+        self.checkHopLimitTruncatedHeader(ancbufsize=socket.CMSG_LEN(0) - 1)
+
+    @testSingleCmsgTruncLen0Minus1.client_skip
+    def _testSingleCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT")
+    def testSingleCmsgTruncInData(self):
+        # Test truncation of a control message inside its associated
+        # data.  The message may be returned with its data truncated,
+        # or not returned at all.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG), socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        self.assertLessEqual(len(ancdata), 1)
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            self.assertEqual(cmsg_type, socket.IPV6_HOPLIMIT)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+    @testSingleCmsgTruncInData.client_skip
+    def _testSingleCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    def checkTruncatedSecondHeader(self, ancbufsize, ignoreflags=0):
+        # Receive traffic class and hop limit into ancbufsize bytes of
+        # ancillary data space, which should be large enough to
+        # contain the first item, but too small to contain the header
+        # of the second.  Check that data is MSG, MSG_CTRUNC is set
+        # (unless included in ignoreflags), and only one ancillary
+        # data item is returned.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock,
+                                                   len(MSG), ancbufsize)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC,
+                        ignore=ignoreflags)
+
+        self.assertEqual(len(ancdata), 1)
+        cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        self.assertIn(cmsg_type, {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT})
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+    # Try the above test with various buffer sizes.
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc0(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT),
+                                        ignoreflags=socket.MSG_CTRUNC)
+
+    @testSecondCmsgTrunc0.client_skip
+    def _testSecondCmsgTrunc0(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) + 1)
+
+    @testSecondCmsgTrunc1.client_skip
+    def _testSecondCmsgTrunc1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTrunc2Int(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        2 * SIZEOF_INT)
+
+    @testSecondCmsgTrunc2Int.client_skip
+    def _testSecondCmsgTrunc2Int(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecondCmsgTruncLen0Minus1(self):
+        self.checkTruncatedSecondHeader(socket.CMSG_SPACE(SIZEOF_INT) +
+                                        socket.CMSG_LEN(0) - 1)
+
+    @testSecondCmsgTruncLen0Minus1.client_skip
+    def _testSecondCmsgTruncLen0Minus1(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+    @requireAttrs(socket, "CMSG_SPACE", "IPV6_RECVHOPLIMIT", "IPV6_HOPLIMIT",
+                  "IPV6_RECVTCLASS", "IPV6_TCLASS")
+    def testSecomdCmsgTruncInData(self):
+        # Test truncation of the second of two control messages inside
+        # its associated data.
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVHOPLIMIT, 1)
+        self.serv_sock.setsockopt(socket.IPPROTO_IPV6,
+                                  socket.IPV6_RECVTCLASS, 1)
+        self.misc_event.set()
+        msg, ancdata, flags, addr = self.doRecvmsg(
+            self.serv_sock, len(MSG),
+            socket.CMSG_SPACE(SIZEOF_INT) + socket.CMSG_LEN(SIZEOF_INT) - 1)
+
+        self.assertEqual(msg, MSG)
+        self.checkRecvmsgAddress(addr, self.cli_addr)
+        self.checkFlags(flags, eor=True, checkset=socket.MSG_CTRUNC)
+
+        cmsg_types = {socket.IPV6_TCLASS, socket.IPV6_HOPLIMIT}
+
+        cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+        self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+        cmsg_types.remove(cmsg_type)
+        self.assertEqual(len(cmsg_data), SIZEOF_INT)
+        a = array.array("i")
+        a.fromstring(cmsg_data)
+        self.assertGreaterEqual(a[0], 0)
+        self.assertLessEqual(a[0], 255)
+
+        if ancdata:
+            cmsg_level, cmsg_type, cmsg_data = ancdata.pop(0)
+            self.assertEqual(cmsg_level, socket.IPPROTO_IPV6)
+            cmsg_types.remove(cmsg_type)
+            self.assertLess(len(cmsg_data), SIZEOF_INT)
+
+        self.assertEqual(ancdata, [])
+
+    @testSecomdCmsgTruncInData.client_skip
+    def _testSecomdCmsgTruncInData(self):
+        self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout))
+        self.sendToServer(MSG)
+
+
+# Derive concrete test classes for different socket types.
+
+class SendrecvmsgUDPTestBase(SendrecvmsgDgramFlagsBase,
+                             SendrecvmsgConnectionlessBase,
+                             ThreadedSocketTestMixin, UDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDPTest(SendmsgConnectionlessTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDPTest(RecvmsgTests, SendrecvmsgUDPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDPTest(RecvmsgIntoTests, SendrecvmsgUDPTestBase):
+    pass
+
+
+class SendrecvmsgUDP6TestBase(SendrecvmsgDgramFlagsBase,
+                              SendrecvmsgConnectionlessBase,
+                              ThreadedSocketTestMixin, UDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUDP6Test(SendmsgConnectionlessTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUDP6Test(RecvmsgTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUDP6Test(RecvmsgIntoTests, SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgRFC3542AncillaryUDP6Test(RFC3542AncillaryTest,
+                                      SendrecvmsgUDP6TestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(socket.has_ipv6, "Python not built with IPv6 support")
+ at requireAttrs(socket, "IPPROTO_IPV6")
+ at requireSocket("AF_INET6", "SOCK_DGRAM")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoRFC3542AncillaryUDP6Test(RecvmsgIntoMixin,
+                                          RFC3542AncillaryTest,
+                                          SendrecvmsgUDP6TestBase):
+    pass
+
+
+class SendrecvmsgTCPTestBase(SendrecvmsgConnectedBase,
+                             ConnectedStreamTestMixin, TCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgTCPTest(SendmsgStreamTests, SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgTCPTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                     SendrecvmsgTCPTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoTCPTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                         SendrecvmsgTCPTestBase):
+    pass
+
+
+class SendrecvmsgSCTPStreamTestBase(SendrecvmsgSCTPFlagsBase,
+                                    SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, SCTPStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgSCTPStreamTest(SendmsgStreamTests, SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCTPStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgSCTPStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireSocket("AF_INET", "SOCK_STREAM", "IPPROTO_SCTP")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCTPStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgSCTPStreamTestBase):
+    pass
+
+
+class SendrecvmsgUnixStreamTestBase(SendrecvmsgConnectedBase,
+                                    ConnectedStreamTestMixin, UnixStreamBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class SendmsgUnixStreamTest(SendmsgStreamTests, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgUnixStreamTest(RecvmsgTests, RecvmsgGenericStreamTests,
+                            SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoUnixStreamTest(RecvmsgIntoTests, RecvmsgGenericStreamTests,
+                                SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgSCMRightsStreamTest(SCMRightsTest, SendrecvmsgUnixStreamTestBase):
+    pass
+
+ at requireAttrs(socket.socket, "sendmsg", "recvmsg_into")
+ at requireAttrs(socket, "AF_UNIX", "SOL_SOCKET", "SCM_RIGHTS")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class RecvmsgIntoSCMRightsStreamTest(RecvmsgIntoMixin, SCMRightsTest,
+                                     SendrecvmsgUnixStreamTestBase):
+    pass
+
+
+# Test interrupting the interruptible send/receive methods with a
+# signal when a timeout is set.  These tests avoid having multiple
+# threads alive during the test so that the OS cannot deliver the
+# signal to the wrong one.
+
+class InterruptedTimeoutBase(unittest.TestCase):
+    # Base class for interrupted send/receive tests.  Installs an
+    # empty handler for SIGALRM and removes it on teardown, along with
+    # any scheduled alarms.
+
+    def setUp(self):
+        super().setUp()
+        orig_alrm_handler = signal.signal(signal.SIGALRM,
+                                          lambda signum, frame: None)
+        self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler)
+        self.addCleanup(self.setAlarm, 0)
+
+    # Timeout for socket operations
+    timeout = 4.0
+
+    # Provide setAlarm() method to schedule delivery of SIGALRM after
+    # given number of seconds, or cancel it if zero, and an
+    # appropriate time value to use.  Use setitimer() if available.
+    if hasattr(signal, "setitimer"):
+        alarm_time = 0.05
+
+        def setAlarm(self, seconds):
+            signal.setitimer(signal.ITIMER_REAL, seconds)
+    else:
+        # Old systems may deliver the alarm up to one second early
+        alarm_time = 2
+
+        def setAlarm(self, seconds):
+            signal.alarm(seconds)
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+class InterruptedRecvTimeoutTest(InterruptedTimeoutBase, UDPTestBase):
+    # Test interrupting the recv*() methods with signals when a
+    # timeout is set.
+
+    def setUp(self):
+        super().setUp()
+        self.serv.settimeout(self.timeout)
+
+    def checkInterruptedRecv(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs) raises socket.error with an
+        # errno of EINTR when interrupted by a signal.
+        self.setAlarm(self.alarm_time)
+        with self.assertRaises(socket.error) as cm:
+            func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedRecvTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv, 1024)
+
+    def testInterruptedRecvIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recv_into, bytearray(1024))
+
+    def testInterruptedRecvfromTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom, 1024)
+
+    def testInterruptedRecvfromIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvfrom_into, bytearray(1024))
+
+    @requireAttrs(socket.socket, "recvmsg")
+    def testInterruptedRecvmsgTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg, 1024)
+
+    @requireAttrs(socket.socket, "recvmsg_into")
+    def testInterruptedRecvmsgIntoTimeout(self):
+        self.checkInterruptedRecv(self.serv.recvmsg_into, [bytearray(1024)])
+
+
+# Require siginterrupt() in order to ensure that system calls are
+# interrupted by default.
+ at requireAttrs(signal, "siginterrupt")
+ at unittest.skipUnless(hasattr(signal, "alarm") or hasattr(signal, "setitimer"),
+                     "Don't have signal.alarm or signal.setitimer")
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class InterruptedSendTimeoutTest(InterruptedTimeoutBase,
+                                 ThreadSafeCleanupTestCase,
+                                 SocketListeningTestMixin, TCPTestBase):
+    # Test interrupting the interruptible send*() methods with signals
+    # when a timeout is set.
+
+    def setUp(self):
+        super().setUp()
+        self.serv_conn = self.newSocket()
+        self.addCleanup(self.serv_conn.close)
+        # Use a thread to complete the connection, but wait for it to
+        # terminate before running the test, so that there is only one
+        # thread to accept the signal.
+        cli_thread = threading.Thread(target=self.doConnect)
+        cli_thread.start()
+        self.cli_conn, addr = self.serv.accept()
+        self.addCleanup(self.cli_conn.close)
+        cli_thread.join()
+        self.serv_conn.settimeout(self.timeout)
+
+    def doConnect(self):
+        self.serv_conn.connect(self.serv_addr)
+
+    def checkInterruptedSend(self, func, *args, **kwargs):
+        # Check that func(*args, **kwargs), run in a loop, raises
+        # socket.error with an errno of EINTR when interrupted by a
+        # signal.
+        with self.assertRaises(socket.error) as cm:
+            while True:
+                self.setAlarm(self.alarm_time)
+                func(*args, **kwargs)
+        self.assertNotIsInstance(cm.exception, socket.timeout)
+        self.assertEqual(cm.exception.errno, errno.EINTR)
+
+    def testInterruptedSendTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.send, b"a"*512)
+
+    def testInterruptedSendtoTimeout(self):
+        # Passing an actual address here as Python's wrapper for
+        # sendto() doesn't allow passing a zero-length one; POSIX
+        # requires that the address is ignored since the socket is
+        # connection-mode, however.
+        self.checkInterruptedSend(self.serv_conn.sendto, b"a"*512,
+                                  self.serv_addr)
+
+    @requireAttrs(socket.socket, "sendmsg")
+    def testInterruptedSendmsgTimeout(self):
+        self.checkInterruptedSend(self.serv_conn.sendmsg, [b"a"*512])
+
+
 @unittest.skipUnless(thread, 'Threading required for this test.')
 class TCPCloserTest(ThreadedTCPSocketTest):
 
@@ -2088,6 +4183,31 @@ def test_main():
     if isTipcAvailable():
         tests.append(TIPCTest)
         tests.append(TIPCThreadableTest)
+    tests.extend([
+        CmsgMacroTests,
+        SendmsgUDPTest,
+        RecvmsgUDPTest,
+        RecvmsgIntoUDPTest,
+        SendmsgUDP6Test,
+        RecvmsgUDP6Test,
+        RecvmsgRFC3542AncillaryUDP6Test,
+        RecvmsgIntoRFC3542AncillaryUDP6Test,
+        RecvmsgIntoUDP6Test,
+        SendmsgTCPTest,
+        RecvmsgTCPTest,
+        RecvmsgIntoTCPTest,
+        SendmsgSCTPStreamTest,
+        RecvmsgSCTPStreamTest,
+        RecvmsgIntoSCTPStreamTest,
+        SendmsgUnixStreamTest,
+        RecvmsgUnixStreamTest,
+        RecvmsgIntoUnixStreamTest,
+        RecvmsgSCMRightsStreamTest,
+        RecvmsgIntoSCMRightsStreamTest,
+        # These are slow when setitimer() is not available
+        InterruptedRecvTimeoutTest,
+        InterruptedSendTimeoutTest,
+    ])
 
     thread_info = support.threading_setup()
     support.run_unittest(*tests)
diff --git a/Lib/test/test_ssl.py b/Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py
+++ b/Lib/test/test_ssl.py
@@ -1496,17 +1496,30 @@ else:
                     count, addr = s.recvfrom_into(b)
                     return b[:count]
 
+                def _recvmsg(*args, **kwargs):
+                    return s.recvmsg(*args, **kwargs)[0]
+
+                def _recvmsg_into(bufsize, *args, **kwargs):
+                    b = bytearray(bufsize)
+                    return bytes(b[:s.recvmsg_into([b], *args, **kwargs)[0]])
+
+                def _sendmsg(msg, *args, **kwargs):
+                    return s.sendmsg([msg])
+
                 # (name, method, whether to expect success, *args)
                 send_methods = [
                     ('send', s.send, True, []),
                     ('sendto', s.sendto, False, ["some.address"]),
+                    ('sendmsg', _sendmsg, False, []),
                     ('sendall', s.sendall, True, []),
                 ]
                 recv_methods = [
                     ('recv', s.recv, True, []),
                     ('recvfrom', s.recvfrom, False, ["some.address"]),
+                    ('recvmsg', _recvmsg, False, [100]),
                     ('recv_into', _recv_into, True, []),
                     ('recvfrom_into', _recvfrom_into, False, []),
+                    ('recvmsg_into', _recvmsg_into, False, [100]),
                 ]
                 data_prefix = "PREFIX_"
 
diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -263,6 +263,7 @@ if_indextoname(index) -- returns the cor
 #ifdef HAVE_NET_IF_H
 #include <net/if.h>
 #endif
+#include <unistd.h>
 
 /* Generic socket object definitions and includes */
 #define PySocket_BUILDING_SOCKET
@@ -469,6 +470,17 @@ static PyTypeObject sock_type;
 #include <sys/poll.h>
 #endif
 
+/* Largest value to try to store in a socklen_t (used when handling
+   ancillary data).  POSIX requires socklen_t to hold at least
+   (2**31)-1 and recommends against storing larger values, but
+   socklen_t was originally int in the BSD interface, so to be on the
+   safe side we use the smaller of (2**31)-1 and INT_MAX. */
+#if INT_MAX > 0x7fffffff
+#define SOCKLEN_T_LIMIT 0x7fffffff
+#else
+#define SOCKLEN_T_LIMIT INT_MAX
+#endif
+
 #ifdef Py_SOCKET_FD_CAN_BE_GE_FD_SETSIZE
 /* Platform can select file descriptors beyond FD_SETSIZE */
 #define IS_SELECTABLE(s) 1
@@ -1678,6 +1690,117 @@ getsockaddrlen(PySocketSockObject *s, so
 }
 
 
+/* Support functions for the sendmsg() and recvmsg[_into]() methods.
+   Currently, these methods are only compiled if the RFC 2292/3542
+   CMSG_LEN() macro is available.  Older systems seem to have used
+   sizeof(struct cmsghdr) + (length) where CMSG_LEN() is used now, so
+   it may be possible to define CMSG_LEN() that way if it's not
+   provided.  Some architectures might need extra padding after the
+   cmsghdr, however, and CMSG_LEN() would have to take account of
+   this. */
+#ifdef CMSG_LEN
+/* If length is in range, set *result to CMSG_LEN(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_LEN(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    if (length > (SOCKLEN_T_LIMIT - CMSG_LEN(0)))
+        return 0;
+    tmp = CMSG_LEN(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+
+#ifdef CMSG_SPACE
+/* If length is in range, set *result to CMSG_SPACE(length) and return
+   true; otherwise, return false. */
+static int
+get_CMSG_SPACE(size_t length, size_t *result)
+{
+    size_t tmp;
+
+    /* Use CMSG_SPACE(1) here in order to take account of the padding
+       necessary before *and* after the data. */
+    if (length > (SOCKLEN_T_LIMIT - CMSG_SPACE(1)))
+        return 0;
+    tmp = CMSG_SPACE(length);
+    if (tmp > SOCKLEN_T_LIMIT || tmp < length)
+        return 0;
+    *result = tmp;
+    return 1;
+}
+#endif
+
+/* Return true iff msg->msg_controllen is valid, cmsgh is a valid
+   pointer in msg->msg_control with at least "space" bytes after it,
+   and its cmsg_len member inside the buffer. */
+static int
+cmsg_min_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t space)
+{
+    size_t cmsg_offset;
+    static const size_t cmsg_len_end = (offsetof(struct cmsghdr, cmsg_len) +
+                                        sizeof(cmsgh->cmsg_len));
+
+    if (cmsgh == NULL || msg->msg_control == NULL || msg->msg_controllen < 0)
+        return 0;
+    if (space < cmsg_len_end)
+        space = cmsg_len_end;
+    cmsg_offset = (char *)cmsgh - (char *)msg->msg_control;
+    return (cmsg_offset <= (size_t)-1 - space &&
+            cmsg_offset + space <= msg->msg_controllen);
+}
+
+/* If pointer CMSG_DATA(cmsgh) is in buffer msg->msg_control, set
+   *space to number of bytes following it in the buffer and return
+   true; otherwise, return false.  Assumes cmsgh, msg->msg_control and
+   msg->msg_controllen are valid. */
+static int
+get_cmsg_data_space(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *space)
+{
+    size_t data_offset;
+    char *data_ptr;
+
+    if ((data_ptr = (char *)CMSG_DATA(cmsgh)) == NULL)
+        return 0;
+    data_offset = data_ptr - (char *)msg->msg_control;
+    if (data_offset > msg->msg_controllen)
+        return 0;
+    *space = msg->msg_controllen - data_offset;
+    return 1;
+}
+
+/* If cmsgh is invalid or not contained in the buffer pointed to by
+   msg->msg_control, return -1.  If cmsgh is valid and its associated
+   data is entirely contained in the buffer, set *data_len to the
+   length of the associated data and return 0.  If only part of the
+   associated data is contained in the buffer but cmsgh is otherwise
+   valid, set *data_len to the length contained in the buffer and
+   return 1. */
+static int
+get_cmsg_data_len(struct msghdr *msg, struct cmsghdr *cmsgh, size_t *data_len)
+{
+    size_t space, cmsg_data_len;
+
+    if (!cmsg_min_space(msg, cmsgh, CMSG_LEN(0)) ||
+        cmsgh->cmsg_len < CMSG_LEN(0))
+        return -1;
+    cmsg_data_len = cmsgh->cmsg_len - CMSG_LEN(0);
+    if (!get_cmsg_data_space(msg, cmsgh, &space))
+        return -1;
+    if (space >= cmsg_data_len) {
+        *data_len = cmsg_data_len;
+        return 0;
+    }
+    *data_len = space;
+    return 1;
+}
+#endif    /* CMSG_LEN */
+
+
 /* s._accept() -> (fd, address) */
 
 static PyObject *
@@ -2631,6 +2754,333 @@ PyDoc_STRVAR(recvfrom_into_doc,
 Like recv_into(buffer[, nbytes[, flags]]) but also return the sender's address info.");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/*
+ * Call recvmsg() with the supplied iovec structures, flags, and
+ * ancillary data buffer size (controllen).  Returns the tuple return
+ * value for recvmsg() or recvmsg_into(), with the first item provided
+ * by the supplied makeval() function.  makeval() will be called with
+ * the length read and makeval_data as arguments, and must return a
+ * new reference (which will be decrefed if there is a subsequent
+ * error).  On error, closes any file descriptors received via
+ * SCM_RIGHTS.
+ */
+static PyObject *
+sock_recvmsg_guts(PySocketSockObject *s, struct iovec *iov, int iovlen,
+                  int flags, Py_ssize_t controllen,
+                  PyObject *(*makeval)(ssize_t, void *), void *makeval_data)
+{
+    ssize_t bytes_received = -1;
+    int timeout;
+    sock_addr_t addrbuf;
+    socklen_t addrbuflen;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    PyObject *cmsg_list = NULL, *retval = NULL;
+    void *controlbuf = NULL;
+    struct cmsghdr *cmsgh;
+    size_t cmsgdatalen = 0;
+    int cmsg_status;
+
+    /* XXX: POSIX says that msg_name and msg_namelen "shall be
+       ignored" when the socket is connected (Linux fills them in
+       anyway for AF_UNIX sockets at least).  Normally msg_namelen
+       seems to be set to 0 if there's no address, but try to
+       initialize msg_name to something that won't be mistaken for a
+       real address if that doesn't happen. */
+    if (!getsockaddrlen(s, &addrbuflen))
+        return NULL;
+    memset(&addrbuf, 0, addrbuflen);
+    SAS2SA(&addrbuf)->sa_family = AF_UNSPEC;
+
+    if (controllen < 0 || controllen > SOCKLEN_T_LIMIT) {
+        PyErr_SetString(PyExc_ValueError,
+                        "invalid ancillary data buffer length");
+        return NULL;
+    }
+    if (controllen > 0 && (controlbuf = PyMem_Malloc(controllen)) == NULL)
+        return PyErr_NoMemory();
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    BEGIN_SELECT_LOOP(s)
+    Py_BEGIN_ALLOW_THREADS;
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+    msg.msg_name = SAS2SA(&addrbuf);
+    msg.msg_namelen = addrbuflen;
+    msg.msg_iov = iov;
+    msg.msg_iovlen = iovlen;
+    msg.msg_control = controlbuf;
+    msg.msg_controllen = controllen;
+    timeout = internal_select_ex(s, 0, interval);
+    if (!timeout)
+        bytes_received = recvmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+    END_SELECT_LOOP(s)
+
+    if (bytes_received < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+
+    /* Make list of (level, type, data) tuples from control messages. */
+    if ((cmsg_list = PyList_New(0)) == NULL)
+        goto err_closefds;
+    /* Check for empty ancillary data as old CMSG_FIRSTHDR()
+       implementations didn't do so. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        PyObject *bytes, *tuple;
+        int tmp;
+
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status != 0) {
+            if (PyErr_WarnEx(PyExc_RuntimeWarning,
+                             "received malformed or improperly-truncated "
+                             "ancillary data", 1) == -1)
+                goto err_closefds;
+        }
+        if (cmsg_status < 0)
+            break;
+        if (cmsgdatalen > PY_SSIZE_T_MAX) {
+            PyErr_SetString(socket_error, "control message too long");
+            goto err_closefds;
+        }
+
+        bytes = PyBytes_FromStringAndSize((char *)CMSG_DATA(cmsgh),
+                                          cmsgdatalen);
+        tuple = Py_BuildValue("iiN", (int)cmsgh->cmsg_level,
+                              (int)cmsgh->cmsg_type, bytes);
+        if (tuple == NULL)
+            goto err_closefds;
+        tmp = PyList_Append(cmsg_list, tuple);
+        Py_DECREF(tuple);
+        if (tmp != 0)
+            goto err_closefds;
+
+        if (cmsg_status != 0)
+            break;
+    }
+
+    retval = Py_BuildValue("NOiN",
+                           (*makeval)(bytes_received, makeval_data),
+                           cmsg_list,
+                           (int)msg.msg_flags,
+                           makesockaddr(s->sock_fd, SAS2SA(&addrbuf),
+                                        ((msg.msg_namelen > addrbuflen) ?
+                                         addrbuflen : msg.msg_namelen),
+                                        s->sock_proto));
+    if (retval == NULL)
+        goto err_closefds;
+
+finally:
+    Py_XDECREF(cmsg_list);
+    PyMem_Free(controlbuf);
+    return retval;
+
+err_closefds:
+#ifdef SCM_RIGHTS
+    /* Close all descriptors coming from SCM_RIGHTS, so they don't leak. */
+    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
+         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
+        cmsg_status = get_cmsg_data_len(&msg, cmsgh, &cmsgdatalen);
+        if (cmsg_status < 0)
+            break;
+        if (cmsgh->cmsg_level == SOL_SOCKET &&
+            cmsgh->cmsg_type == SCM_RIGHTS) {
+            size_t numfds;
+            int *fdp;
+
+            numfds = cmsgdatalen / sizeof(int);
+            fdp = (int *)CMSG_DATA(cmsgh);
+            while (numfds-- > 0)
+                close(*fdp++);
+        }
+        if (cmsg_status != 0)
+            break;
+    }
+#endif /* SCM_RIGHTS */
+    goto finally;
+}
+
+
+static PyObject *
+makeval_recvmsg(ssize_t received, void *data)
+{
+    PyObject **buf = data;
+
+    if (received < PyBytes_GET_SIZE(*buf))
+        _PyBytes_Resize(buf, received);
+    Py_XINCREF(*buf);
+    return *buf;
+}
+
+/* s.recvmsg(bufsize[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t bufsize, ancbufsize = 0;
+    int flags = 0;
+    struct iovec iov;
+    PyObject *buf = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "n|ni:recvmsg", &bufsize, &ancbufsize, &flags))
+        return NULL;
+
+    if (bufsize < 0) {
+        PyErr_SetString(PyExc_ValueError, "negative buffer size in recvmsg()");
+        return NULL;
+    }
+    if ((buf = PyBytes_FromStringAndSize(NULL, bufsize)) == NULL)
+        return NULL;
+    iov.iov_base = PyBytes_AS_STRING(buf);
+    iov.iov_len = bufsize;
+
+    /* Note that we're passing a pointer to *our pointer* to the bytes
+       object here (&buf); makeval_recvmsg() may incref the object, or
+       deallocate it and set our pointer to NULL. */
+    retval = sock_recvmsg_guts(s, &iov, 1, flags, ancbufsize,
+                               &makeval_recvmsg, &buf);
+    Py_XDECREF(buf);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_doc,
+"recvmsg(bufsize[, ancbufsize[, flags]]) -> (data, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data (up to bufsize bytes) and ancillary data from the\n\
+socket.  The ancbufsize argument sets the size in bytes of the\n\
+internal buffer used to receive the ancillary data; it defaults to 0,\n\
+meaning that no ancillary data will be received.  Appropriate buffer\n\
+sizes for ancillary data can be calculated using CMSG_SPACE() or\n\
+CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (data, ancdata, msg_flags, address).\n\
+The data item is a bytes object holding the non-ancillary data\n\
+received.  The ancdata item is a list of zero or more tuples\n\
+(cmsg_level, cmsg_type, cmsg_data) representing the ancillary data\n\
+(control messages) received: cmsg_level and cmsg_type are integers\n\
+specifying the protocol level and protocol-specific type respectively,\n\
+and cmsg_data is a bytes object holding the associated data.  The\n\
+msg_flags item is the bitwise OR of various flags indicating\n\
+conditions on the received message; see your system documentation for\n\
+details.  If the receiving socket is unconnected, address is the\n\
+address of the sending socket, if available; otherwise, its value is\n\
+unspecified.\n\
+\n\
+If recvmsg() raises an exception after the system call returns, it\n\
+will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+
+
+static PyObject *
+makeval_recvmsg_into(ssize_t received, void *data)
+{
+    return PyLong_FromSsize_t(received);
+}
+
+/* s.recvmsg_into(buffers[, ancbufsize[, flags]]) method */
+
+static PyObject *
+sock_recvmsg_into(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t ancbufsize = 0;
+    int flags = 0;
+    struct iovec *iovs = NULL;
+    Py_ssize_t i, nitems, nbufs = 0;
+    Py_buffer *bufs = NULL;
+    PyObject *buffers_arg, *fast, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|ni:recvmsg_into",
+                          &buffers_arg, &ancbufsize, &flags))
+        return NULL;
+
+    if ((fast = PySequence_Fast(buffers_arg,
+                                "recvmsg_into() argument 1 must be an "
+                                "iterable")) == NULL)
+        return NULL;
+    nitems = PySequence_Fast_GET_SIZE(fast);
+    if (nitems > INT_MAX) {
+        PyErr_SetString(socket_error, "recvmsg_into() argument 1 is too long");
+        goto finally;
+    }
+
+    /* Fill in an iovec for each item, and save the Py_buffer
+       structs to release afterwards. */
+    if (nitems > 0 && ((iovs = PyMem_New(struct iovec, nitems)) == NULL ||
+                       (bufs = PyMem_New(Py_buffer, nitems)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; nbufs < nitems; nbufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(fast, nbufs),
+                         "w*;recvmsg_into() argument 1 must be an iterable "
+                         "of single-segment read-write buffers",
+                         &bufs[nbufs]))
+            goto finally;
+        iovs[nbufs].iov_base = bufs[nbufs].buf;
+        iovs[nbufs].iov_len = bufs[nbufs].len;
+    }
+
+    retval = sock_recvmsg_guts(s, iovs, nitems, flags, ancbufsize,
+                               &makeval_recvmsg_into, NULL);
+finally:
+    for (i = 0; i < nbufs; i++)
+        PyBuffer_Release(&bufs[i]);
+    PyMem_Free(bufs);
+    PyMem_Free(iovs);
+    Py_DECREF(fast);
+    return retval;
+}
+
+PyDoc_STRVAR(recvmsg_into_doc,
+"recvmsg_into(buffers[, ancbufsize[, flags]]) -> (nbytes, ancdata, msg_flags, address)\n\
+\n\
+Receive normal data and ancillary data from the socket, scattering the\n\
+non-ancillary data into a series of buffers.  The buffers argument\n\
+must be an iterable of objects that export writable buffers\n\
+(e.g. bytearray objects); these will be filled with successive chunks\n\
+of the non-ancillary data until it has all been written or there are\n\
+no more buffers.  The ancbufsize argument sets the size in bytes of\n\
+the internal buffer used to receive the ancillary data; it defaults to\n\
+0, meaning that no ancillary data will be received.  Appropriate\n\
+buffer sizes for ancillary data can be calculated using CMSG_SPACE()\n\
+or CMSG_LEN(), and items which do not fit into the buffer might be\n\
+truncated or discarded.  The flags argument defaults to 0 and has the\n\
+same meaning as for recv().\n\
+\n\
+The return value is a 4-tuple: (nbytes, ancdata, msg_flags, address).\n\
+The nbytes item is the total number of bytes of non-ancillary data\n\
+written into the buffers.  The ancdata item is a list of zero or more\n\
+tuples (cmsg_level, cmsg_type, cmsg_data) representing the ancillary\n\
+data (control messages) received: cmsg_level and cmsg_type are\n\
+integers specifying the protocol level and protocol-specific type\n\
+respectively, and cmsg_data is a bytes object holding the associated\n\
+data.  The msg_flags item is the bitwise OR of various flags\n\
+indicating conditions on the received message; see your system\n\
+documentation for details.  If the receiving socket is unconnected,\n\
+address is the address of the sending socket, if available; otherwise,\n\
+its value is unspecified.\n\
+\n\
+If recvmsg_into() raises an exception after the system call returns,\n\
+it will first attempt to close any file descriptors received via the\n\
+SCM_RIGHTS mechanism.");
+#endif    /* CMSG_LEN */
+
+
 /* s.send(data [,flags]) method */
 
 static PyObject *
@@ -2826,6 +3276,237 @@ Like send(data, flags) but allows specif
 For IP sockets, the address is a pair (hostaddr, port).");
 
 
+/* The sendmsg() and recvmsg[_into]() methods require a working
+   CMSG_LEN().  See the comment near get_CMSG_LEN(). */
+#ifdef CMSG_LEN
+/* s.sendmsg(buffers[, ancdata[, flags[, address]]]) method */
+
+static PyObject *
+sock_sendmsg(PySocketSockObject *s, PyObject *args)
+{
+    Py_ssize_t i, ndataparts, ndatabufs = 0, ncmsgs, ncmsgbufs = 0;
+    Py_buffer *databufs = NULL;
+    struct iovec *iovs = NULL;
+    sock_addr_t addrbuf;
+    static const struct msghdr msg_blank;
+    struct msghdr msg;
+    struct cmsginfo {
+        int level;
+        int type;
+        Py_buffer data;
+    } *cmsgs = NULL;
+    void *controlbuf = NULL;
+    size_t controllen, controllen_last;
+    ssize_t bytes_sent = -1;
+    int addrlen, timeout, flags = 0;
+    PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL,
+        *cmsg_fast = NULL, *retval = NULL;
+
+    if (!PyArg_ParseTuple(args, "O|OiO:sendmsg",
+                          &data_arg, &cmsg_arg, &flags, &addr_arg))
+        return NULL;
+
+    msg = msg_blank;    /* Set all members to 0 or NULL */
+
+    /* Parse destination address. */
+    if (addr_arg != NULL && addr_arg != Py_None) {
+        if (!getsockaddrarg(s, addr_arg, SAS2SA(&addrbuf), &addrlen))
+            goto finally;
+        msg.msg_name = &addrbuf;
+        msg.msg_namelen = addrlen;
+    }
+
+    /* Fill in an iovec for each message part, and save the Py_buffer
+       structs to release afterwards. */
+    if ((data_fast = PySequence_Fast(data_arg,
+                                     "sendmsg() argument 1 must be an "
+                                     "iterable")) == NULL)
+        goto finally;
+    ndataparts = PySequence_Fast_GET_SIZE(data_fast);
+    if (ndataparts > INT_MAX) {
+        PyErr_SetString(socket_error, "sendmsg() argument 1 is too long");
+        goto finally;
+    }
+    msg.msg_iovlen = ndataparts;
+    if (ndataparts > 0 &&
+        ((msg.msg_iov = iovs = PyMem_New(struct iovec, ndataparts)) == NULL ||
+         (databufs = PyMem_New(Py_buffer, ndataparts)) == NULL)) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    for (; ndatabufs < ndataparts; ndatabufs++) {
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(data_fast, ndatabufs),
+                         "y*;sendmsg() argument 1 must be an iterable of "
+                         "buffer-compatible objects",
+                         &databufs[ndatabufs]))
+            goto finally;
+        iovs[ndatabufs].iov_base = databufs[ndatabufs].buf;
+        iovs[ndatabufs].iov_len = databufs[ndatabufs].len;
+    }
+
+    if (cmsg_arg == NULL)
+        ncmsgs = 0;
+    else {
+        if ((cmsg_fast = PySequence_Fast(cmsg_arg,
+                                         "sendmsg() argument 2 must be an "
+                                         "iterable")) == NULL)
+            goto finally;
+        ncmsgs = PySequence_Fast_GET_SIZE(cmsg_fast);
+    }
+
+#ifndef CMSG_SPACE
+    if (ncmsgs > 1) {
+        PyErr_SetString(socket_error,
+                        "sending multiple control messages is not supported "
+                        "on this system");
+        goto finally;
+    }
+#endif
+    /* Save level, type and Py_buffer for each control message,
+       and calculate total size. */
+    if (ncmsgs > 0 && (cmsgs = PyMem_New(struct cmsginfo, ncmsgs)) == NULL) {
+        PyErr_NoMemory();
+        goto finally;
+    }
+    controllen = controllen_last = 0;
+    while (ncmsgbufs < ncmsgs) {
+        size_t bufsize, space;
+
+        if (!PyArg_Parse(PySequence_Fast_GET_ITEM(cmsg_fast, ncmsgbufs),
+                         "(iiy*):[sendmsg() ancillary data items]",
+                         &cmsgs[ncmsgbufs].level,
+                         &cmsgs[ncmsgbufs].type,
+                         &cmsgs[ncmsgbufs].data))
+            goto finally;
+        bufsize = cmsgs[ncmsgbufs++].data.len;
+
+#ifdef CMSG_SPACE
+        if (!get_CMSG_SPACE(bufsize, &space)) {
+#else
+        if (!get_CMSG_LEN(bufsize, &space)) {
+#endif
+            PyErr_SetString(socket_error, "ancillary data item too large");
+            goto finally;
+        }
+        controllen += space;
+        if (controllen > SOCKLEN_T_LIMIT || controllen < controllen_last) {
+            PyErr_SetString(socket_error, "too much ancillary data");
+            goto finally;
+        }
+        controllen_last = controllen;
+    }
+
+    /* Construct ancillary data block from control message info. */
+    if (ncmsgbufs > 0) {
+        struct cmsghdr *cmsgh = NULL;
+
+        if ((msg.msg_control = controlbuf =
+             PyMem_Malloc(controllen)) == NULL) {
+            PyErr_NoMemory();
+            goto finally;
+        }
+        msg.msg_controllen = controllen;
+
+        /* Need to zero out the buffer as a workaround for glibc's
+           CMSG_NXTHDR() implementation.  After getting the pointer to
+           the next header, it checks its (uninitialized) cmsg_len
+           member to see if the "message" fits in the buffer, and
+           returns NULL if it doesn't.  Zero-filling the buffer
+           ensures that that doesn't happen. */
+        memset(controlbuf, 0, controllen);
+
+        for (i = 0; i < ncmsgbufs; i++) {
+            size_t msg_len, data_len = cmsgs[i].data.len;
+            int enough_space = 0;
+
+            cmsgh = (i == 0) ? CMSG_FIRSTHDR(&msg) : CMSG_NXTHDR(&msg, cmsgh);
+            if (cmsgh == NULL) {
+                PyErr_Format(PyExc_RuntimeError,
+                             "unexpected NULL result from %s()",
+                             (i == 0) ? "CMSG_FIRSTHDR" : "CMSG_NXTHDR");
+                goto finally;
+            }
+            if (!get_CMSG_LEN(data_len, &msg_len)) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "item size out of range for CMSG_LEN()");
+                goto finally;
+            }
+            if (cmsg_min_space(&msg, cmsgh, msg_len)) {
+                size_t space;
+
+                cmsgh->cmsg_len = msg_len;
+                if (get_cmsg_data_space(&msg, cmsgh, &space))
+                    enough_space = (space >= data_len);
+            }
+            if (!enough_space) {
+                PyErr_SetString(PyExc_RuntimeError,
+                                "ancillary data does not fit in calculated "
+                                "space");
+                goto finally;
+            }
+            cmsgh->cmsg_level = cmsgs[i].level;
+            cmsgh->cmsg_type = cmsgs[i].type;
+            memcpy(CMSG_DATA(cmsgh), cmsgs[i].data.buf, data_len);
+        }
+    }
+
+    /* Make the system call. */
+    if (!IS_SELECTABLE(s)) {
+        select_error();
+        goto finally;
+    }
+
+    BEGIN_SELECT_LOOP(s)
+    Py_BEGIN_ALLOW_THREADS;
+    timeout = internal_select_ex(s, 1, interval);
+    if (!timeout)
+        bytes_sent = sendmsg(s->sock_fd, &msg, flags);
+    Py_END_ALLOW_THREADS;
+    if (timeout == 1) {
+        PyErr_SetString(socket_timeout, "timed out");
+        goto finally;
+    }
+    END_SELECT_LOOP(s)
+
+    if (bytes_sent < 0) {
+        s->errorhandler();
+        goto finally;
+    }
+    retval = PyLong_FromSsize_t(bytes_sent);
+
+finally:
+    PyMem_Free(controlbuf);
+    for (i = 0; i < ncmsgbufs; i++)
+        PyBuffer_Release(&cmsgs[i].data);
+    PyMem_Free(cmsgs);
+    Py_XDECREF(cmsg_fast);
+    for (i = 0; i < ndatabufs; i++)
+        PyBuffer_Release(&databufs[i]);
+    PyMem_Free(databufs);
+    PyMem_Free(iovs);
+    Py_XDECREF(data_fast);
+    return retval;
+}
+
+PyDoc_STRVAR(sendmsg_doc,
+"sendmsg(buffers[, ancdata[, flags[, address]]]) -> count\n\
+\n\
+Send normal and ancillary data to the socket, gathering the\n\
+non-ancillary data from a series of buffers and concatenating it into\n\
+a single message.  The buffers argument specifies the non-ancillary\n\
+data as an iterable of buffer-compatible objects (e.g. bytes objects).\n\
+The ancdata argument specifies the ancillary data (control messages)\n\
+as an iterable of zero or more tuples (cmsg_level, cmsg_type,\n\
+cmsg_data), where cmsg_level and cmsg_type are integers specifying the\n\
+protocol level and protocol-specific type respectively, and cmsg_data\n\
+is a buffer-compatible object holding the associated data.  The flags\n\
+argument defaults to 0 and has the same meaning as for send().  If\n\
+address is supplied and not None, it sets a destination address for\n\
+the message.  The return value is the number of bytes of non-ancillary\n\
+data sent.");
+#endif    /* CMSG_LEN */
+
+
 /* s.shutdown(how) method */
 
 static PyObject *
@@ -2952,6 +3633,14 @@ static PyMethodDef sock_methods[] = {
                       setsockopt_doc},
     {"shutdown",          (PyCFunction)sock_shutdown, METH_O,
                       shutdown_doc},
+#ifdef CMSG_LEN
+    {"recvmsg",           (PyCFunction)sock_recvmsg, METH_VARARGS,
+                      recvmsg_doc},
+    {"recvmsg_into",      (PyCFunction)sock_recvmsg_into, METH_VARARGS,
+                      recvmsg_into_doc,},
+    {"sendmsg",           (PyCFunction)sock_sendmsg, METH_VARARGS,
+                      sendmsg_doc},
+#endif
     {NULL,                      NULL}           /* sentinel */
 };
 
@@ -4377,6 +5066,68 @@ Returns the interface name corresponding
 #endif  /* HAVE_IF_NAMEINDEX */
 
 
+#ifdef CMSG_LEN
+/* Python interface to CMSG_LEN(length). */
+
+static PyObject *
+socket_CMSG_LEN(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_LEN", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_LEN(length, &result)) {
+        PyErr_Format(PyExc_OverflowError, "CMSG_LEN() argument out of range");
+        return NULL;
+    }
+    return PyLong_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_LEN_doc,
+"CMSG_LEN(length) -> control message length\n\
+\n\
+Return the total length, without trailing padding, of an ancillary\n\
+data item with associated data of the given length.  This value can\n\
+often be used as the buffer size for recvmsg() to receive a single\n\
+item of ancillary data, but RFC 3542 requires portable applications to\n\
+use CMSG_SPACE() and thus include space for padding, even when the\n\
+item will be the last in the buffer.  Raises OverflowError if length\n\
+is outside the permissible range of values.");
+
+
+#ifdef CMSG_SPACE
+/* Python interface to CMSG_SPACE(length). */
+
+static PyObject *
+socket_CMSG_SPACE(PyObject *self, PyObject *args)
+{
+    Py_ssize_t length;
+    size_t result;
+
+    if (!PyArg_ParseTuple(args, "n:CMSG_SPACE", &length))
+        return NULL;
+    if (length < 0 || !get_CMSG_SPACE(length, &result)) {
+        PyErr_SetString(PyExc_OverflowError,
+                        "CMSG_SPACE() argument out of range");
+        return NULL;
+    }
+    return PyLong_FromSize_t(result);
+}
+
+PyDoc_STRVAR(CMSG_SPACE_doc,
+"CMSG_SPACE(length) -> buffer size\n\
+\n\
+Return the buffer size needed for recvmsg() to receive an ancillary\n\
+data item with associated data of the given length, along with any\n\
+trailing padding.  The buffer space needed to receive multiple items\n\
+is the sum of the CMSG_SPACE() values for their associated data\n\
+lengths.  Raises OverflowError if length is outside the permissible\n\
+range of values.");
+#endif    /* CMSG_SPACE */
+#endif    /* CMSG_LEN */
+
+
 /* List of functions exported by this module. */
 
 static PyMethodDef socket_methods[] = {
@@ -4440,6 +5191,14 @@ static PyMethodDef socket_methods[] = {
     {"if_indextoname", socket_if_indextoname,
      METH_O, if_indextoname_doc},
 #endif
+#ifdef CMSG_LEN
+    {"CMSG_LEN",                socket_CMSG_LEN,
+     METH_VARARGS, CMSG_LEN_doc},
+#ifdef CMSG_SPACE
+    {"CMSG_SPACE",              socket_CMSG_SPACE,
+     METH_VARARGS, CMSG_SPACE_doc},
+#endif
+#endif
     {NULL,                      NULL}            /* Sentinel */
 };
 
@@ -4927,6 +5686,15 @@ PyInit__socket(void)
 #ifdef  SO_SETFIB
     PyModule_AddIntConstant(m, "SO_SETFIB", SO_SETFIB);
 #endif
+#ifdef  SO_PASSCRED
+    PyModule_AddIntConstant(m, "SO_PASSCRED", SO_PASSCRED);
+#endif
+#ifdef  SO_PEERCRED
+    PyModule_AddIntConstant(m, "SO_PEERCRED", SO_PEERCRED);
+#endif
+#ifdef  LOCAL_PEERCRED
+    PyModule_AddIntConstant(m, "LOCAL_PEERCRED", LOCAL_PEERCRED);
+#endif
 
     /* Maximum number of connections for "listen" */
 #ifdef  SOMAXCONN
@@ -4935,6 +5703,17 @@ PyInit__socket(void)
     PyModule_AddIntConstant(m, "SOMAXCONN", 5); /* Common value */
 #endif
 
+    /* Ancilliary message types */
+#ifdef  SCM_RIGHTS
+    PyModule_AddIntConstant(m, "SCM_RIGHTS", SCM_RIGHTS);
+#endif
+#ifdef  SCM_CREDENTIALS
+    PyModule_AddIntConstant(m, "SCM_CREDENTIALS", SCM_CREDENTIALS);
+#endif
+#ifdef  SCM_CREDS
+    PyModule_AddIntConstant(m, "SCM_CREDS", SCM_CREDS);
+#endif
+
     /* Flags for send, recv */
 #ifdef  MSG_OOB
     PyModule_AddIntConstant(m, "MSG_OOB", MSG_OOB);
@@ -4966,6 +5745,33 @@ PyInit__socket(void)
 #ifdef  MSG_ETAG
     PyModule_AddIntConstant(m, "MSG_ETAG", MSG_ETAG);
 #endif
+#ifdef  MSG_NOSIGNAL
+    PyModule_AddIntConstant(m, "MSG_NOSIGNAL", MSG_NOSIGNAL);
+#endif
+#ifdef  MSG_NOTIFICATION
+    PyModule_AddIntConstant(m, "MSG_NOTIFICATION", MSG_NOTIFICATION);
+#endif
+#ifdef  MSG_CMSG_CLOEXEC
+    PyModule_AddIntConstant(m, "MSG_CMSG_CLOEXEC", MSG_CMSG_CLOEXEC);
+#endif
+#ifdef  MSG_ERRQUEUE
+    PyModule_AddIntConstant(m, "MSG_ERRQUEUE", MSG_ERRQUEUE);
+#endif
+#ifdef  MSG_CONFIRM
+    PyModule_AddIntConstant(m, "MSG_CONFIRM", MSG_CONFIRM);
+#endif
+#ifdef  MSG_MORE
+    PyModule_AddIntConstant(m, "MSG_MORE", MSG_MORE);
+#endif
+#ifdef  MSG_EOF
+    PyModule_AddIntConstant(m, "MSG_EOF", MSG_EOF);
+#endif
+#ifdef  MSG_BCAST
+    PyModule_AddIntConstant(m, "MSG_BCAST", MSG_BCAST);
+#endif
+#ifdef  MSG_MCAST
+    PyModule_AddIntConstant(m, "MSG_MCAST", MSG_MCAST);
+#endif
 
     /* Protocol level and numbers, usable for [gs]etsockopt */
 #ifdef  SOL_SOCKET
@@ -5105,6 +5911,9 @@ PyInit__socket(void)
 #ifdef  IPPROTO_VRRP
     PyModule_AddIntConstant(m, "IPPROTO_VRRP", IPPROTO_VRRP);
 #endif
+#ifdef  IPPROTO_SCTP
+    PyModule_AddIntConstant(m, "IPPROTO_SCTP", IPPROTO_SCTP);
+#endif
 #ifdef  IPPROTO_BIP
     PyModule_AddIntConstant(m, "IPPROTO_BIP", IPPROTO_BIP);
 #endif

From report at bugs.python.org  Mon May 30 00:00:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 May 2011 22:00:12 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306695180.87.0.816522980689.issue12196@psf.upfronthosting.co.za>
Message-ID: <201105300000.05934.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> If've added a test to skip this test on Linux kernels older than 2.6.27:
> like O_CLOEXEC, the problem is that the libc defines pipe2() while the
> kernel doesn't support it, so when syscall() is called it bails out with
> ENOSYS. (This buildbot should really have its libc/kernel upgraded...)

You may add the issue number of your commit changelog, so a comment is 
generated directly in the issue.

support.linux_version() may be changed for requires_linux_version(2, 6, 27), 
but linux_version() is always used in tests to check the Linux version. 
requires_linux_version() would only raise a SkipTest if the OS is Linux and if 
the kernel is lesser than the specified version.

By the way, I like the new os.pipe2() function! You may want to document it in 
the "What's new in Python 3.3" doc (just mention the new function, the 
document will be rephrased later).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Mon May 30 00:29:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 22:29:43 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <E1QQoUP-00058Y-Nw@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset de4d34a95603 by Ned Deily in branch 'default':
Issue #10736: Fix test_ttk test_widgets failures with Cocoa Tk 8.5.9
http://hg.python.org/cpython/rev/de4d34a95603

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Mon May 30 00:40:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 22:40:51 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <E1QQofC-0005s6-1F@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset c2f61149764e by Ned Deily in branch 'default':
Issue #10736: Revert changeset de4d34a95603 as it causes failures with
http://hg.python.org/cpython/rev/c2f61149764e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Mon May 30 00:46:44 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 May 2011 22:46:44 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1306709204.52.0.894719047738.issue10736@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The changes looked good to me and fixed the test failures with Cocoa Tk 8.5.9 and caused no regressions with the ActiveState Carbon Tk 8.4 so I committed them to get some exposure.  But then I recalled I had not tested with just the old Apple-supplied Tk 8.4 and, of course, the test fails there.  So reverting for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Mon May 30 01:02:30 2011
From: report at bugs.python.org (umedoblock)
Date: Sun, 29 May 2011 23:02:30 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>


New submission from umedoblock <umedoblock at gmail.com>:

I expected return int if I gave x as integer to copysign.

I encounterd two problems.
I'd like to fix this problems.
but I can't come up with nice idea.
therefore I just report for you.

one:
>>> import math
>>> a = [0, 1, 2, 3]
>>> i = 1
>>> i_copysign = math.copysign(i, -1)
>>> a[i_copysign]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not float

two:
>>> n = 10 ** 20
>>> math.copysign(n + 1, 1) == n + 1
False

----------
components: Library (Lib)
messages: 137226
nosy: umedoblock
priority: normal
severity: normal
status: open
title: math.copysign must keep object type.
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Mon May 30 01:16:19 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 May 2011 23:16:19 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1306710979.41.0.307692719568.issue10736@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It appears the original (unmodified) test also fails with the old Apple-supplied Tk 8.4 (this is on OS X 10.5).  So I'll do some more testing and then probably re-apply this at some point after the current round of releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Mon May 30 01:17:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2011 23:17:00 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <E1QQpEB-0007sz-C9@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 48e837b2a327 by Nadeem Vawda in branch 'default':
Miscellaneous cleanups to bz2 and test_bz2 following issue #1625.
http://hg.python.org/cpython/rev/48e837b2a327

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon May 30 01:17:59 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 29 May 2011 23:17:59 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306711079.66.0.151291759889.issue12084@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file22182/patch_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 30 01:19:15 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 29 May 2011 23:19:15 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1306711155.91.0.790949713036.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> If you?re logged into Roundup, you should automatically be logged into
> our Rietveld instance.

I thought this was the case, but it isn't working for me. I've filed a
bug on the meta-tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon May 30 01:21:47 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 29 May 2011 23:21:47 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306711307.7.0.861477498435.issue12084@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file22183/patch_v2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 30 01:22:04 2011
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 29 May 2011 23:22:04 +0000
Subject: [issue12084] os.stat() on windows doesn't consider relative symlink
In-Reply-To: <1305514402.69.0.449438068729.issue12084@psf.upfronthosting.co.za>
Message-ID: <1306711324.12.0.725208583239.issue12084@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file22006/patches_v2.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12084>
_______________________________________

From report at bugs.python.org  Mon May 30 02:01:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 00:01:17 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <E1QQpv2-0001uA-Cm@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3e5200abf8eb by Nadeem Vawda in branch 'default':
Issue #1625: Add stream ordering test to test_bz2.
http://hg.python.org/cpython/rev/3e5200abf8eb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Mon May 30 02:23:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 00:23:36 +0000
Subject: [issue12209] Minor edits to faulthandler doc
In-Reply-To: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>
Message-ID: <1306715016.35.0.971142062232.issue12209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What do you call a "stack trace"? I use this term in the C language, especially when using the "where" command of gdb. In Python, the stack trace is called a "traceback". Anyway, faulthandler prints the Python trace, not the C trace, so I prefer to call it a "traceback" than "stack trace".

faulthandler.dump_traceback() output is similar to:

    try:
        raise ValueError()
    except:
        exctype, value, tb = sys.exc_info()
        traceback.print_tb(tb)

faulthandler doesn't print the line from the script, only the function name, file name and line number; and the first line is different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12209>
_______________________________________

From report at bugs.python.org  Mon May 30 02:30:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 00:30:52 +0000
Subject: [issue12175] FileIO.readall() read the file position and size at each
	read
In-Reply-To: <1306325640.48.0.610014463103.issue12175@psf.upfronthosting.co.za>
Message-ID: <1306715452.42.0.764559908239.issue12175@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/issue12175>
_______________________________________

From report at bugs.python.org  Mon May 30 02:33:28 2011
From: report at bugs.python.org (Joesph)
Date: Mon, 30 May 2011 00:33:28 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306631941.06.0.285250029675.issue12203@psf.upfronthosting.co.za>
Message-ID: <BANLkTinUR5NEN_9JBM5e+iQifM8Cz53DAw@mail.gmail.com>


Joesph <someone3x7 at gmail.com> added the comment:

And much sense is made. If there is a generic instance test that I have
missed I'd be willing to work around this minor flaw. That the definition is
an instance of 'object' is a case that should be handled by the function
though.
On May 28, 2011 6:19 PM, "Benjamin Peterson" <report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> Everything is an instance of object.
>
> ----------
> nosy: +benjamin.peterson
> resolution: -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12203>
> _______________________________________

----------
Added file: http://bugs.python.org/file22184/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________
-------------- next part --------------
<p>And much sense is made. If there is a generic instance test that I have missed I&#39;d be willing to work around this minor flaw. That the definition is an instance of &#39;object&#39; is a case that should be handled by the function though.</p>

<div class="gmail_quote">On May 28, 2011 6:19 PM, &quot;Benjamin Peterson&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br type="attribution">&gt; <br>&gt; Benjamin Peterson &lt;<a href="mailto:benjamin at python.org">benjamin at python.org</a>&gt; added the comment:<br>
&gt; <br>&gt; Everything is an instance of object.<br>&gt; <br>&gt; ----------<br>&gt; nosy: +benjamin.peterson<br>&gt; resolution:  -&gt; invalid<br>&gt; status: open -&gt; closed<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/issue12203">http://bugs.python.org/issue12203</a>&gt;<br>&gt; _______________________________________<br>
</div>

From report at bugs.python.org  Mon May 30 04:07:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 02:07:44 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1306721264.01.0.924050147297.issue12211@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Mon May 30 04:09:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 02:09:53 +0000
Subject: [issue12211] math.copysign must keep object type.
In-Reply-To: <1306710150.53.0.509116993934.issue12211@psf.upfronthosting.co.za>
Message-ID: <1306721393.56.0.344024710828.issue12211@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"Except when explicitly noted otherwise, all return values are floats."

On the other hand, copysign says "return x with the sign of y", which certainly sounds like it is preserving x, not creating a new float.  So at the least there is a doc issue, I think.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12211>
_______________________________________

From report at bugs.python.org  Mon May 30 04:14:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 02:14:34 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>
Message-ID: <1306721674.47.0.190216900184.issue12203@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Everything in python is an instance of something.  Objects all the way down...

>>> isinstance(object, object)
True

So, there is no function you are overlooking because there is nothing that is not an instance.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________

From report at bugs.python.org  Mon May 30 04:18:37 2011
From: report at bugs.python.org (Mitch Ackermann)
Date: Mon, 30 May 2011 02:18:37 +0000
Subject: [issue12212] Minor proofreading typo in index.rst
In-Reply-To: <1306721917.28.0.135738146271.issue12212@psf.upfronthosting.co.za>
Message-ID: <1306721917.28.0.135738146271.issue12212@psf.upfronthosting.co.za>


New submission from Mitch Ackermann <ma at plethory.net>:

-Here are some links that you may find you refererence frequently while
+Here are some links that you may find you reference frequently while

----------
components: Devguide
messages: 137235
nosy: mita
priority: normal
severity: normal
status: open
title: Minor proofreading typo in index.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12212>
_______________________________________

From report at bugs.python.org  Mon May 30 04:29:38 2011
From: report at bugs.python.org (Joesph)
Date: Mon, 30 May 2011 02:29:38 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306721674.47.0.190216900184.issue12203@psf.upfronthosting.co.za>
Message-ID: <BANLkTim6cXbGSLm--s5w-FbjoxKXkKUt0g@mail.gmail.com>


Joesph <someone3x7 at gmail.com> added the comment:

It only fails when checking for 'object'. To think classes are instances is
absurd. Its like saying the chicken is the egg. I can understand that
classes are an instance of object in the interpreter, but, that isn't the
case in the interpreted. Thus this is an unhandled case.

To accept your answer would mean it is a pointless function that should be
removed altogether. But that is not the case as this example works as
expected:

class A(object):
    pass

class B(A):
    pass

C = B()

print([isinstance(B,A),isinstance(C,A)])

# outputs: [False, True]

You did make it obvious to me why the object case was failing and for that I
am grateful. It will make it easier to work around when I get back to that
part of the code.

On Sun, May 29, 2011 at 7:14 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Everything in python is an instance of something.  Objects all the way
> down...
>
> >>> isinstance(object, object)
> True
>
> So, there is no function you are overlooking because there is nothing that
> is not an instance.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12203>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22185/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________
-------------- next part --------------
It only fails when checking for &#39;object&#39;. To think classes are instances is absurd. Its like saying the chicken is the egg. I can understand that classes are an instance of object in the interpreter, but, that isn&#39;t the case in the interpreted. Thus this is an unhandled case. <br>
<br>To accept your answer would mean it is a pointless function that should be removed altogether. But that is not the case as this example works as expected:<br><br>class A(object):<br>?????? pass<br><br>class B(A):<br>?????? pass<br>
<br>C = B()<br><br>print([isinstance(B,A),isinstance(C,A)])<br><br># outputs: [False, True]<br><br>You did make it obvious to me why the object case was failing and for that I am grateful. It will make it easier to work around when I get back to that part of the code.<br>
<br><div class="gmail_quote">On Sun, May 29, 2011 at 7:14 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
Everything in python is an instance of something. ??Objects all the way down...<br>
<br>
&gt;&gt;&gt; isinstance(object, object)<br>
True<br>
<br>
So, there is no function you are overlooking because there is nothing that is not an instance.<br>
<br>
----------<br>
nosy: +r.david.murray<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/issue12203" target="_blank">http://bugs.python.org/issue12203</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>

From report at bugs.python.org  Mon May 30 04:43:39 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 30 May 2011 02:43:39 +0000
Subject: [issue12212] Minor proofreading typo in index.rst
In-Reply-To: <1306721917.28.0.135738146271.issue12212@psf.upfronthosting.co.za>
Message-ID: <1306723419.09.0.453628295618.issue12212@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

e685024a2699

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12212>
_______________________________________

From report at bugs.python.org  Mon May 30 04:52:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 02:52:39 +0000
Subject: [issue12213] BufferedRandom: write();
	read() gives different result using io and _pyio
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code displays "Xbc" using io, and "bc" using _pyio (or an unbuffered file, e.g. io.FileIO):
-------------
import _pyio, io

with io.BytesIO(b'abc') as raw:
    #with _pyio.BufferedRandom(raw) as f:
    with io.BufferedRandom(raw) as f:
        f.write(b"X")
        print("pos?", f.tell(), raw.tell())
        print(f.read())
-------------

I expect .write() to change the file position, and so "bc" must be the correct result, not "Wbc".

_pyio.BufferedRandom overrides its write method, whereas io.BufferedRandom doesn't.

I already noticed the implement difference of BufferedRandom.write(), but I don't remember if I reported it or not!?

----------
messages: 137238
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: BufferedRandom: write(); read() gives different result using io and _pyio
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 04:52:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 02:52:58 +0000
Subject: [issue12213] BufferedRandom: write();
	read() gives different result using io and _pyio
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306723978.97.0.865969278354.issue12213@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +IO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 04:54:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 02:54:51 +0000
Subject: [issue12213] BufferedRandom: write();
	read() gives different result using io and _pyio
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306724091.96.0.494558358022.issue12213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I already noticed the implement difference of BufferedRandom.write(),
> but I don't remember if I reported it or not!?

Yes, I already reported the difference:
http://bugs.python.org/issue12062#msg135876

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 05:20:08 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 30 May 2011 03:20:08 +0000
Subject: [issue12213] BufferedRandom: write();
	read() gives different result using io and _pyio
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306725608.71.0.587762052922.issue12213@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/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 05:20:48 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 30 May 2011 03:20:48 +0000
Subject: [issue12062] Buffered I/O inconsistent with unbuffered I/O in certain
	cases
In-Reply-To: <1305205648.13.0.328834738921.issue12062@psf.upfronthosting.co.za>
Message-ID: <1306725648.11.0.849147755002.issue12062@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/issue12062>
_______________________________________

From report at bugs.python.org  Mon May 30 06:28:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 04:28:10 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306629694.09.0.59463520917.issue12203@psf.upfronthosting.co.za>
Message-ID: <1306729690.9.0.901263178661.issue12203@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are correct, B is not an instance of A.  But both B and A are instances of 'type':

>>> class A:
...   pass
...
>>> class B(A):
...    pass
...
>>> isinstance(A, type)
True
>>> isinstance(B, type)
True
>>> 

And type is a subclass of object.  isinstance is correct, because Python is consistent.  As we said, *everything* is an object.

If you want to know if something is a class, you can check isinstance(X, type):

>>> a = A()
>>> isinstance(a, type)
False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________

From report at bugs.python.org  Mon May 30 06:30:34 2011
From: report at bugs.python.org (Joesph)
Date: Mon, 30 May 2011 04:30:34 +0000
Subject: [issue12203] isinstance not functioning as documented
In-Reply-To: <1306729690.9.0.901263178661.issue12203@psf.upfronthosting.co.za>
Message-ID: <BANLkTimdTT_igvycGb8rx5MggN0+HPJCBw@mail.gmail.com>


Joesph <someone3x7 at gmail.com> added the comment:

Beautiful, thank you. This should be in the isinstance documentation for
clarity.
On May 29, 2011 9:28 PM, "R. David Murray" <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> You are correct, B is not an instance of A. But both B and A are instances
of 'type':
>
>>>> class A:
> ... pass
> ...
>>>> class B(A):
> ... pass
> ...
>>>> isinstance(A, type)
> True
>>>> isinstance(B, type)
> True
>>>>
>
> And type is a subclass of object. isinstance is correct, because Python is
consistent. As we said, *everything* is an object.
>
> If you want to know if something is a class, you can check isinstance(X,
type):
>
>>>> a = A()
>>>> isinstance(a, type)
> False
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12203>
> _______________________________________

----------
Added file: http://bugs.python.org/file22186/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12203>
_______________________________________
-------------- next part --------------
<p>Beautiful, thank you. This should be in the isinstance documentation for clarity.</p>
<div class="gmail_quote">On May 29, 2011 9:28 PM, &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; You are correct, B is not an instance of A.  But both B and A are instances of &#39;type&#39;:<br>&gt; <br>&gt;&gt;&gt;&gt; class A:<br>&gt; ...   pass<br>&gt; ...<br>&gt;&gt;&gt;&gt; class B(A):<br>&gt; ...    pass<br>
&gt; ...<br>&gt;&gt;&gt;&gt; isinstance(A, type)<br>&gt; True<br>&gt;&gt;&gt;&gt; isinstance(B, type)<br>&gt; True<br>&gt;&gt;&gt;&gt; <br>&gt; <br>&gt; And type is a subclass of object.  isinstance is correct, because Python is consistent.  As we said, *everything* is an object.<br>
&gt; <br>&gt; If you want to know if something is a class, you can check isinstance(X, type):<br>&gt; <br>&gt;&gt;&gt;&gt; a = A()<br>&gt;&gt;&gt;&gt; isinstance(a, type)<br>&gt; False<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/issue12203">http://bugs.python.org/issue12203</a>&gt;<br>
&gt; _______________________________________<br></div>

From report at bugs.python.org  Mon May 30 06:58:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 04:58:41 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <1306505461.65.0.724394863657.issue12196@psf.upfronthosting.co.za>
Message-ID: <1306731521.06.0.208290375555.issue12196@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FYI that buildbot is likely to get a kernel upgrade in the not too distant future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Mon May 30 07:22:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 05:22:21 +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: <1306732941.65.0.0799661721734.issue11975@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You are confusing directives and roles.  As was already pointed out, there is currently no target for list.append to point to.  That's what needs to be added.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 07:36:35 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 30 May 2011 05:36:35 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306733795.06.0.913495545619.issue11623@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What 10.7? ;-) Please remember 10.7 is under NDA, and as such shouldn't be discussed in public.

As I mentioned earlier: the 32-bit build should be deprecated and is only needed for older machines, anyone running modern machines can install OSX 10.6 (or later) and can use the intel-only build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Mon May 30 08:08:42 2011
From: report at bugs.python.org (sorin)
Date: Mon, 30 May 2011 06:08:42 +0000
Subject: [issue11623] Distutils is reporting OSX 10.6 w/ XCode 4 as "universal"
In-Reply-To: <1300725819.97.0.991086015608.issue11623@psf.upfronthosting.co.za>
Message-ID: <1306735722.56.0.794662095097.issue11623@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

FYI, I got the above output from 10.7 from a friend, I do not have access to the seed, so the information could be wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11623>
_______________________________________

From report at bugs.python.org  Mon May 30 10:10:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 30 May 2011 08:10:15 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306666020.34.0.114942173152.issue12206@psf.upfronthosting.co.za>
Message-ID: <1306743015.45.0.0970451753993.issue12206@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The name of the "level" parameter to LogRecord constructor is correct in the documentation (I checked the code). The only inconsitency that I see is that the corresponding attribute name of LogRecord is "levelno".

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Mon May 30 10:28:30 2011
From: report at bugs.python.org (Martin Ponweiser)
Date: Mon, 30 May 2011 08:28:30 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <1306743015.45.0.0970451753993.issue12206@psf.upfronthosting.co.za>
Message-ID: <BANLkTi=0Y=2ufQFn86Agpo_hjM8wyvFhzQ@mail.gmail.com>


Martin Ponweiser <m.ponweiser at gmail.com> added the comment:

You are right, I should have looked closer -- sorry to all involved.
Nevertheless this caused some confusion here. I guess mentioning the
inconsistency in the documentation is out of the question.

On Mon, May 30, 2011 at 10:10 AM, Petri Lehtinen <report at bugs.python.org>wrote:

>
> Petri Lehtinen <petri at digip.org> added the comment:
>
> The name of the "level" parameter to LogRecord constructor is correct in
> the documentation (I checked the code). The only inconsitency that I see is
> that the corresponding attribute name of LogRecord is "levelno".
>
> ----------
> nosy: +petri.lehtinen
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12206>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22187/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________
-------------- next part --------------
You are right, I should have looked closer -- sorry to all involved. Nevertheless this caused some confusion here. I guess mentioning the inconsistency in the documentation is out of the question.<br><br><div class="gmail_quote">
On Mon, May 30, 2011 at 10:10 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>
Petri Lehtinen &lt;<a href="mailto:petri at digip.org">petri at digip.org</a>&gt; added the comment:<br>
<br>
The name of the &quot;level&quot; parameter to LogRecord constructor is correct in the documentation (I checked the code). The only inconsitency that I see is that the corresponding attribute name of LogRecord is &quot;levelno&quot;.<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/issue12206" target="_blank">http://bugs.python.org/issue12206</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Martin Ponweiser<br>Frauengasse 4/8, 2700 Wr. Neustadt, Austria<br>cell phone: 0043 650-68 27 949 (no SMS inbox)<br>

From report at bugs.python.org  Mon May 30 10:33:18 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 30 May 2011 08:33:18 +0000
Subject: [issue12206] Documentation Std. Library 15.7.5 "LogRecord objects":
	Parameters: level(currently wrong) -> levelno (correct)
In-Reply-To: <BANLkTi=0Y=2ufQFn86Agpo_hjM8wyvFhzQ@mail.gmail.com>
Message-ID: <20110530083316.GD24535@colossus>


Petri Lehtinen <petri at digip.org> added the comment:

Martin Ponweiser wrote:
> I guess mentioning the inconsistency in the documentation is out of
> the question.

No, not at all. If you have a good wording in your mind, please share
it :) Or even better, write a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12206>
_______________________________________

From report at bugs.python.org  Mon May 30 10:54:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 08:54:54 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1306745694.35.0.0618865388828.issue1195@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Mon May 30 11:02:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 30 May 2011 09:02:33 +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: <1306746153.39.0.536295915448.issue12198@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

On 2.7, your example raises an error:

Traceback (most recent call last):
  File "a.py", line 7, in <module>
    z.write("a", "a")
  File "/home/petri/tmp/cpython/cpython/Lib/zipfile.py", line 1071, in write
    self.fp.write(zinfo.FileHeader())
  File "/home/petri/tmp/cpython/cpython/Lib/zipfile.py", line 348, in FileHeader
    len(filename), len(extra))
struct.error: ushort format requires 0 <= number <= USHRT_MAX

I doubt this can be fixed in 2.6 anymore, as it's in security fix only -mode.

What comes to the error on 2.7, it could be better. If zip files simply don't support dates before 1980, an error describing this could be raised. Another possibility would be to clamp too old dates to 1980.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12198>
_______________________________________

From report at bugs.python.org  Mon May 30 11:06:19 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 30 May 2011 09:06:19 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1306746379.16.0.625582772872.issue12014@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/issue12014>
_______________________________________

From report at bugs.python.org  Mon May 30 11:42:06 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 30 May 2011 09:42:06 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1306748526.65.0.518713470316.issue12151@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The last change appears to have fixed the problem; AFAIK there have been no test_logging failures on the buildbots for several days.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 30 11:44:42 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 30 May 2011 09:44:42 +0000
Subject: [issue12068] test_logging failure in test_rollover
In-Reply-To: <1305237732.24.0.707153494768.issue12068@psf.upfronthosting.co.za>
Message-ID: <1306748682.85.0.945421880682.issue12068@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There appear to have been no test_logging failures on the buildbots for around a week, so closing this issue. A change to ignore socket errors when the server was closed appears to have done the trick.

----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12068>
_______________________________________

From report at bugs.python.org  Mon May 30 12:00:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 10:00:51 +0000
Subject: [issue12151] test_logging fails sometimes
In-Reply-To: <1306106163.56.0.790245092521.issue12151@psf.upfronthosting.co.za>
Message-ID: <1306749651.13.0.462105964571.issue12151@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The last change appears to have fixed the problem; 
> AFAIK there have been no test_logging failures on the buildbots 
> for several days.

Great job, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12151>
_______________________________________

From report at bugs.python.org  Mon May 30 12:14:40 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 30 May 2011 10:14:40 +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: <1306750480.76.0.66753974822.issue11254@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

to be backported in packaging -- in a way that will make it work with previous python versions for the incoming 2.x backport

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Mon May 30 12:38:53 2011
From: report at bugs.python.org (Jonas H.)
Date: Mon, 30 May 2011 10:38:53 +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: <1306751933.07.0.250319995675.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

I'm not.

My patch doesn't address the problem of unlinkable methods but wrong type declarations (read, wrong usage of ".. function::" directives) for builtins like int, float, bool, list etc. Because the directives change, the roles used to link to them (":func:`list`") have to be changed accordingly.  That's what this patch does.

I want to address `list` method documentation in the next step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 12:57:29 2011
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 30 May 2011 10:57:29 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1306753049.42.0.911578509385.issue6490@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Per msg129958, attached is my stab at a patch to replace most uses of os.popen() with the subprocess module. The test suite passes on my Mac, but the patch does touch some specific-to-other-platform code, so further testing is obviously needed.
This is my first non-docs patch, please be gentle. :) [Those patches were to subprocess' docs though!]

Stuff still using os.popen() that the patch doesn't fix:
- multiprocessing
- platform.popen() [which is itself deprecated]
- subprocess.check_output()
- Lib/test/test_poll.py
- Lib/test/test_select.py
- Lib/distutils/tests/test_cygwinccompiler.py

Also, I suppose Issue 9382 should be marked as a dupe of this one?

----------
nosy: +cvrebert
Added file: http://bugs.python.org/file22188/mostly_replace_os_popen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Mon May 30 13:27:32 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 30 May 2011 11:27:32 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1306753049.42.0.911578509385.issue6490@psf.upfronthosting.co.za>
Message-ID: <4DE37F1F.1060903@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Chris Rebert wrote:
> 
> Chris Rebert <pybugs at rebertia.com> added the comment:
> 
> Per msg129958, attached is my stab at a patch to replace most uses of os.popen() with the subprocess module. The test suite passes on my Mac, but the patch does touch some specific-to-other-platform code, so further testing is obviously needed.
> This is my first non-docs patch, please be gentle. :) [Those patches were to subprocess' docs though!]
> 
> Stuff still using os.popen() that the patch doesn't fix:
> - multiprocessing
> - platform.popen() [which is itself deprecated]
> - subprocess.check_output()
> - Lib/test/test_poll.py
> - Lib/test/test_select.py
> - Lib/distutils/tests/test_cygwinccompiler.py
> 
> Also, I suppose Issue 9382 should be marked as a dupe of this one?

Thanks, but I still don't understand why os.popen() wasn't removed
from the list of deprecated APIs as per Guido's message further up
on the ticket.

If you look at the amount of code you need to add in order
to support the os.popen() functionality directly using
subprocess instead of going the indirect way via the existing
os.popen() wrapper around the subprocess functionality, I think
this shows that the wrapper is indeed a good thing to have
and something you'd otherwise implement anyway as part of
standard code refactoring.

So instead of applying such a patch, I think we should add back
the documentation for os.popen() and remove the deprecation
notices.

The deprecations for os.popenN() are still fine, since those
APIs are not used all that much, and I'm sure that no one can
really remember what all the different versions do anyway :-)

os.popen() OTOH is often used and implements a very common
use: running an external command and getting the stdout
results back for further processing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Mon May 30 13:30:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 11:30:46 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306755046.82.0.835448303312.issue12213@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: BufferedRandom: write(); read() gives different result using io and _pyio -> BufferedRandom, BufferedRWPair: issues with interlaced read-write

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 13:37:11 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 30 May 2011 11:37:11 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1306755431.72.0.107009196697.issue12125@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Tarek, can you confirm that the bug is closed?. It is reported as "open" in the tracker.

Could you possibly close it, if appropiate?.

----------
assignee: tarek -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12125>
_______________________________________

From report at bugs.python.org  Mon May 30 13:46:20 2011
From: report at bugs.python.org (zhou wei)
Date: Mon, 30 May 2011 11:46:20 +0000
Subject: [issue12214] platform module can't detect archlinux distribution
In-Reply-To: <1306755980.67.0.396964353848.issue12214@psf.upfronthosting.co.za>
Message-ID: <1306755980.67.0.396964353848.issue12214@psf.upfronthosting.co.za>


New submission from zhou wei <lilaboc.cn at gmail.com>:

platform.py can't detect archlinux distribution.
the fix is to try to detect whether /etc/arch-release exists (archlinux is using a rolling release model, so no version, id here. https://wiki.archlinux.org/index.php/Arch_Linux).

----------
components: Library (Lib)
files: platform.py.patch
keywords: patch
messages: 137258
nosy: lemburg, lilaboc
priority: normal
severity: normal
status: open
title: platform module can't detect archlinux distribution
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22189/platform.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12214>
_______________________________________

From report at bugs.python.org  Mon May 30 13:57:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 11:57:31 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306756651.54.0.607962084751.issue12213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

io_interlaced_read_write.patch:
 - add interlaced read/write tests for BufferedRandom and BufferedRWPair
 - _pyio: move "undo readahead" code into BufferedReader.flush()
 - io: BufferedRandom.flush() doesn't undo readahead if the write buffer is empty, so it's possible to call it in read methods without flusing the readahead buffer when it's not needed
 - read(), read1(), readinto(), peek() calls writer.flush()
 - write() calls reader.flush() (undo readahead)

TODO:
 - tests BufferedRWPair with read-only + write-only files because I'm not sure if my tests using readable and writeable methods
 - _pyio: undo the readahead in BufferedReader.flush() is no perfect, because BufferedReader is supposed to be read-only. I choosed that to factorize the code between BufferedRandom and BufferedRWPair
 - what happens if a write occurs during _pyio.BufferedReader.flush()? "if self._read_buf: <write occurs> with self._read_lock: ...". We may protect the read of self._read_buf with the read lock.

My patch tries to fix interlaced read-write by always calling flush(), but I am not sure that it doesn't change read-only and write-only cases. There are maybe some unnecessary call to flush().

----------
keywords: +patch
Added file: http://bugs.python.org/file22190/io_interlaced_read_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 14:38:02 2011
From: report at bugs.python.org (zhou wei)
Date: Mon, 30 May 2011 12:38:02 +0000
Subject: [issue12214] platform module can't detect archlinux distribution
In-Reply-To: <1306755980.67.0.396964353848.issue12214@psf.upfronthosting.co.za>
Message-ID: <1306759082.32.0.347470665555.issue12214@psf.upfronthosting.co.za>


Changes by zhou wei <lilaboc.cn at gmail.com>:


Removed file: http://bugs.python.org/file22189/platform.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12214>
_______________________________________

From report at bugs.python.org  Mon May 30 14:38:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 12:38:04 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

The following code fails on an assertion error (Python exception for _pyio, C assertion for io):

------------------
with io.BytesIO(b'abcd') as raw:
    with _pyio.TextIOWrapper(raw, encoding='ascii') as f:
        f.read(1)
        f.write('2')
        f.tell()
------------------

I found this assertion while testing interlaced read-write on TextIOWrapper:
------------------
with io.BytesIO(b'abcd') as raw:
    with _pyio.TextIOWrapper(raw, encoding='ascii') as f:
        f.write("1")
        # read() must call writer.flush()
        assertEqual(f.read(1), 'b')
        # write() must rewind the raw stream
        f.write('2')
        assertEqual(f.read(), 'd')
        f.flush()
        assertEqual(raw.getvalue(), b'1b2d')

with io.BytesIO(b'abc') as raw:
    with _pyio.TextIOWrapper(raw, encoding='ascii') as f:
        self.assertEqual(f.read(1), b'a')
        # write() must undo reader readahead
        f.write(b"2")
        assertEqual(f.read(1), b'c')
        f.flush()
        assertEqual(raw.getvalue(), b'a2c')
------------------
These tests fails on "read, write, read" path: write() breaks TextIOWrapper internal state if a read() occured just before. Note that _pyio.TextIOWrapper.write() contains the following comment...

# XXX What if we were just reading?

See also the issue #12213 for BufferedRandom and BufferedRWPair.

----------
components: IO
messages: 137260
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: TextIOWrapper: issues with interlaced read-write
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12215>
_______________________________________

From report at bugs.python.org  Mon May 30 14:38:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 12:38:36 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306759116.61.0.0952488701664.issue12213@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #12215: TextIOWrapper has also issues on interlaced read-write.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 14:39:13 2011
From: report at bugs.python.org (zhou wei)
Date: Mon, 30 May 2011 12:39:13 +0000
Subject: [issue12214] platform module can't detect archlinux distribution
In-Reply-To: <1306755980.67.0.396964353848.issue12214@psf.upfronthosting.co.za>
Message-ID: <1306759153.97.0.992633281995.issue12214@psf.upfronthosting.co.za>


Changes by zhou wei <lilaboc.cn at gmail.com>:


Added file: http://bugs.python.org/file22191/platform.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12214>
_______________________________________

From report at bugs.python.org  Mon May 30 15:07:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 13:07:56 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1306760876.36.0.403847066891.issue12215@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

textiowrapper_interlaced_read_write.patch: TextIOWrapper.write() calls self.seek(self.tell()) if it has a decoder or if snapshot is not None.

I suppose that we can do better, but at least it does fix this issue.

"read(); write(); write()" only calls self.seek(self.tell()) once, at the first write. So I don't think that it changes anything with performances.

In which case snapshot can be not different than None, whereas decoder is None?

----------
keywords: +patch
Added file: http://bugs.python.org/file22192/textiowrapper_interlaced_read_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12215>
_______________________________________

From report at bugs.python.org  Mon May 30 15:08:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 13:08:13 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1306760893.35.0.451375517089.issue12215@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12215>
_______________________________________

From report at bugs.python.org  Mon May 30 15:08:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 13:08:20 +0000
Subject: [issue12215] TextIOWrapper: issues with interlaced read-write
In-Reply-To: <1306759084.05.0.928785750761.issue12215@psf.upfronthosting.co.za>
Message-ID: <1306760900.13.0.666413115021.issue12215@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12215>
_______________________________________

From report at bugs.python.org  Mon May 30 15:08:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 13:08:27 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1306760907.27.0.736194725475.issue12213@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Mon May 30 15:26:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 13:26:14 +0000
Subject: [issue11864] sporadic failure in test_concurrent_futures
In-Reply-To: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>
Message-ID: <E1QR2U0-0004PO-L6@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7e99da22c26d by Brian Quinlan in branch 'default':
Increases some test timeouts to fix issue 11864.
http://hg.python.org/cpython/rev/7e99da22c26d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11864>
_______________________________________

From report at bugs.python.org  Mon May 30 15:26:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:26:29 +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: <1306761989.56.0.740527255815.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could you make an effort to accept our word that using :class: instead of :func: would bring zero value to the indexing system nor to human readers?

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 15:28:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:28:00 +0000
Subject: [issue12209] Minor edits to faulthandler doc
In-Reply-To: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>
Message-ID: <1306762080.47.0.171850145377.issue12209@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> faulthandler prints the Python trace, not the C trace, so I prefer to
> call it a "traceback" than "stack trace".
Okay.  What do you think about this synopsis then: dumping the traceback on CPython crashes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12209>
_______________________________________

From report at bugs.python.org  Mon May 30 15:30:25 2011
From: report at bugs.python.org (Alex Leach)
Date: Mon, 30 May 2011 13:30:25 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306762225.72.0.751338002742.issue11946@psf.upfronthosting.co.za>


Alex Leach <beamesleach at gmail.com> added the comment:

I got the same test_commands fail when building a Python2.7.1 which I downloaded yesterday; it's on an FC13 x86_64 server.
I've built python2.7 before using a similar machine, but it's not picking up my external libraries on a Sun Grid Engine, leaving me with import errors. Probably problems with the environment ($PYTHONHOME & $PYTHONPATH), but playing with these don't fix my batch jobs, so I've decided to build a cross-compiled version, which I've done on a Mac Pro before, but not a linux server, where --with-universal-archs doesn't work. I'm not a guru with using CFLAGS args during compilation, so I think I'll end up compiling it twice (long, I need this to work yesterday), using Jason's configure arguments (that -m32 is the ticket), and taking Jason's wrapper script, modifying it for my home dir. Thanks for posting that Jason!! I'd already started implementing something similar in my batch script, but yours looks much more thorough.
Whilst here, I wanted to advocate python a bit. I think it's awesome, and an article that articulates it's awesomeness fairly amusingly, can be found here:-
http://www.linuxjournal.com/article/3882
Still, I'm also disappointed with these build problems. I left `make test` running overnight and it had hung, using 100% of a CPU the whole night. I'm not even half-way to getting python compiled... :( Will probably also need to recompile ATLAS as well as numpy / biopython for both archs - no quick or easy feat.

----------
nosy: +Alex.Leach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 15:30:50 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 30 May 2011 13:30:50 +0000
Subject: [issue11864] sporadic failure in test_concurrent_futures
In-Reply-To: <1303085572.99.0.967761591602.issue11864@psf.upfronthosting.co.za>
Message-ID: <1306762250.21.0.784829842155.issue11864@psf.upfronthosting.co.za>


Changes by Brian Quinlan <brian at sweetapp.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11864>
_______________________________________

From report at bugs.python.org  Mon May 30 15:30:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:30:58 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306762258.36.0.952028399924.issue11416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  One remark: instead of using keys() + getitem in Lib/netrc.py:109, you can use this: for host, attrs in self.allhosts.items()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 15:31:51 2011
From: report at bugs.python.org (Jonas H.)
Date: Mon, 30 May 2011 13:31:51 +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: <1306762311.87.0.123249828901.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

> Could you make an effort to accept our word that using :class: instead of :func: would bring zero value to the indexing system nor to human readers?

I'm already doing; but I don't see anyone having made a good point against my preference of using ".. class::" to document classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 15:32:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:32:32 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1306762352.26.0.509096448876.issue10772@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I would not document 'parsers'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Mon May 30 15:32:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:32:57 +0000
Subject: [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1306762377.59.0.235193549623.issue12207@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay.  I?ll make another patch to remove mentions of this flag then.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12207>
_______________________________________

From report at bugs.python.org  Mon May 30 15:37:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:37:38 +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: <1306762658.78.0.853819955109.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I'm already doing;
Thanks.

> but I don't see anyone having made a good point against my preference
> of using ".. class::" to document classes.
We have agreed it is needed (I think it?s on another bug report, maybe a duplicate).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 15:39:28 2011
From: report at bugs.python.org (Jonas H.)
Date: Mon, 30 May 2011 13:39:28 +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: <1306762768.18.0.199146525484.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

What's wrong with the changes I propose with the patch, then? Sorry, I really don't get it, no matter how hard I try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 15:51:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:51:36 +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: <1306763496.03.0.558943602936.issue11975@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Due to implementation details and history of CPython, it is not ?more correct? to say that int is a function and a class.  You could argue either.  The question is however moot; when you mark up something with a mod, func, class or meth role, Sphinx will find the target without paying attention to its type.  So changing :func: to :class: does not bring anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 15:52:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 13:52:08 +0000
Subject: [issue12209] Minor edits to faulthandler doc
In-Reply-To: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>
Message-ID: <1306763528.71.0.828631335819.issue12209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> dumping the traceback on CPython crashes?

faulthandler is no more specific to crashes: you can dump the tracebacks while Python is running using a signal or an explicit call to faulthandler.dump_traceback().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12209>
_______________________________________

From report at bugs.python.org  Mon May 30 15:54:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 13:54:29 +0000
Subject: [issue12209] Minor edits to faulthandler doc
In-Reply-To: <1306690203.86.0.276499968085.issue12209@psf.upfronthosting.co.za>
Message-ID: <1306763669.83.0.989959199777.issue12209@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, I understand now that the traceback always exists, not only during exceptions.  The module gives control over the display of that traceback.  Am I right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12209>
_______________________________________

From report at bugs.python.org  Mon May 30 16:04:36 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Mon, 30 May 2011 14:04:36 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306764276.11.0.851217161302.issue11416@psf.upfronthosting.co.za>


Jean-Marc Saffroy <saffroy at gmail.com> added the comment:

You are suggesting something like this, I suppose?

--- a/Lib/netrc.py
+++ b/Lib/netrc.py
@@ -105,8 +105,8 @@ class netrc:
     def __repr__(self):
         """Dump the class data in the format of a .netrc file."""
         rep = ""
-        for host in self.allhosts.keys():
-            for attrs in self.allhosts[host]:
+        for (host, attrlist) in self.allhosts.items():
+            for attrs in attrlist:
                 rep = rep + "machine "+ host + "\n\tlogin " + repr(attrs[0]) + "\n"
                 if attrs[1]:
                     rep = rep + "account " + repr(attrs[1])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 16:05:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 14:05:54 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306764354.05.0.438156789322.issue11416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Exactly, minus the parens (not needed).

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 16:14:02 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Mon, 30 May 2011 14:14:02 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306764842.02.0.426043202172.issue11416@psf.upfronthosting.co.za>


Jean-Marc Saffroy <saffroy at gmail.com> added the comment:

Patch slightly updated after Eric's comments.

----------
Added file: http://bugs.python.org/file22193/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 16:18:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 14:18:38 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306765118.35.0.984697022337.issue11416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m surprised self.assert_ does not produce a DeprecationWarning (in favor of assertTrue).  The tests should use assertEqual(expected, computed) anyway, to let developers see a useful diff when the test fails.  Could you change this in the tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 16:19:34 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Mon, 30 May 2011 14:19:34 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306765174.65.0.54108324409.issue11416@psf.upfronthosting.co.za>


Jean-Marc Saffroy <saffroy at gmail.com> added the comment:

Patch formatting changed to be more review-friendly (looks like MQ-style patch isn't?), otherwise same as 2011-05-30 16:14.

----------
Added file: http://bugs.python.org/file22194/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 16:21:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 14:21:50 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1306765310.03.0.0437994097214.issue1322@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, doko applied this patch for Debian and Ubuntu: http://patch-tracker.debian.org/patch/series/view/python3.2/3.2.1~rc1-1/platform-lsbrelease.diff

----------
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Mon May 30 16:24:30 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Mon, 30 May 2011 14:24:30 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306765470.41.0.876108092687.issue11416@psf.upfronthosting.co.za>


Jean-Marc Saffroy <saffroy at gmail.com> added the comment:

Eric: yes I can look into the asserts, but note I generated and tested my patch from a checkout of 2.6 (see my first report), so maybe that's why I didn't see any warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 16:32:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 14:32:18 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306765938.73.0.301990456162.issue11416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, okay.  Your patch needs to apply to 2.7 or 3.2, which use assertEqual and not assert_.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 16:38:41 2011
From: report at bugs.python.org (Jonas H.)
Date: Mon, 30 May 2011 14:38:41 +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: <1306766321.5.0.223828807458.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

> when you mark up something with a mod, func, class or meth role, Sphinx will find the target without paying attention to its type.  So changing :func: to :class: does not bring anything.

>From a quick test this seems to hold true for links within one project but not for Sphinx' intersphinx extension, which actually cares about types.

So the question is whether we keep CPython implementation details (many builtins being both a class and a function) out of the documentation or we get the Sphinx developers to change intersphinx behaviour.  I guess you'd suggest the latter, right? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 16:54:57 2011
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Mon, 30 May 2011 14:54:57 +0000
Subject: [issue12216] future imports change the reporting of syntaxerrors
In-Reply-To: <1306767297.7.0.76540444561.issue12216@psf.upfronthosting.co.za>
Message-ID: <1306767297.7.0.76540444561.issue12216@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <ronny.pfannschmidt at gmail.com>:

>>> compile('def foo(', '', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 1
    def foo(
          ^
SyntaxError: unexpected EOF while parsing

vs

>>> compile('from __future__ import print_function\ndef foo(', '', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 2
    def foo(
          ^
SyntaxError: invalid syntax

----------
messages: 137285
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: future imports change the reporting of syntaxerrors
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12216>
_______________________________________

From report at bugs.python.org  Mon May 30 17:02:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 15:02:04 +0000
Subject: [issue12216] future imports change the reporting of syntaxerrors
In-Reply-To: <1306767297.7.0.76540444561.issue12216@psf.upfronthosting.co.za>
Message-ID: <1306767724.8.0.495480060172.issue12216@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/issue12216>
_______________________________________

From report at bugs.python.org  Mon May 30 17:03:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 15:03:16 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306767796.54.0.155116159882.issue11946@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The test_commands fix will be in 2.7.2.  2.7.1 was released well before the fix was made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 17:04:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 15:04:56 +0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1306767896.1.0.352244526994.issue1322@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

http://patch-tracker.debian.org/patch/series/view/python3.2/3.2.1~rc1-1/platform-lsbrelease.diff

This patch fails if "(?:DISTRIB_CODENAME\s*=)\s*(.*)" regex doesn't match (_u_id variable is not set).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________

From report at bugs.python.org  Mon May 30 17:09:39 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Mon, 30 May 2011 15:09:39 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306768179.73.0.788226461257.issue11416@psf.upfronthosting.co.za>


Jean-Marc Saffroy <saffroy at gmail.com> added the comment:

Here is a patch against 2.7.

----------
Added file: http://bugs.python.org/file22195/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 17:10:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 15:10:48 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306768248.82.0.957688093548.issue11416@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file21444/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 17:10:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 15:10:51 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306768251.86.0.735593083253.issue11416@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22193/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 17:10:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 15:10:53 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306768253.94.0.684203181574.issue11416@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22194/netrc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 17:11:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 15:11:25 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306768285.41.0.786157979763.issue11416@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great!  Could you expand the docstrings and reST documentation to mention the new behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Mon May 30 17:12:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 15:12:04 +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: <1306768324.76.0.103937827449.issue11975@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It should certainly be reported to the sphinx tracker where the right people to make the decision for sphinx itself will see it.  Then if the decision is that type matters, python can decide how we want to handle that fact.  Since the core of sphinx does not care about type, I suspect this will be viewed as a bug in InterSphinx, but I could well be wrong.

Note that not using :func: does change the generated text.  With :func: you get () after the name, with :class: you don't.  So changing :func: to :class: for these is a decision that would need some discussion.

Also note that I'm guessing that there will be people who will object to expanding the description of the sequence types into full class/method docs.  So this, too, is a change that needs to be discussed with a wider audience.  I think I'm +0 on it myself; it makes the docs less concise and leads to redundant text, but it also make it easier to look up the method set of individual sequence types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 17:16:34 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 30 May 2011 15:16:34 +0000
Subject: [issue9326] Error message for incorrect number of (function) args is
	incorrect
In-Reply-To: <1279745047.45.0.24813200138.issue9326@psf.upfronthosting.co.za>
Message-ID: <1306768594.5.0.677049744505.issue9326@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

FWIW, this case is tested in PyPy: http://paste.pocoo.org/show/397732/

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9326>
_______________________________________

From report at bugs.python.org  Mon May 30 17:17:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 15:17:27 +0000
Subject: [issue12188] PEP 7, C style: add ++ policy and explanation
In-Reply-To: <1306433972.91.0.882585972593.issue12188@psf.upfronthosting.co.za>
Message-ID: <1306768647.85.0.199496485552.issue12188@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/issue12188>
_______________________________________

From report at bugs.python.org  Mon May 30 17:20:57 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 30 May 2011 15:20:57 +0000
Subject: [issue9326] Error message for incorrect number of (function) args is
	incorrect
In-Reply-To: <1279745047.45.0.24813200138.issue9326@psf.upfronthosting.co.za>
Message-ID: <1306768857.26.0.0829382513708.issue9326@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think some one should just rewrite this code from scratch. Every time I fix something, it breaks something else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9326>
_______________________________________

From report at bugs.python.org  Mon May 30 17:22:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 15:22:16 +0000
Subject: [issue9382] os.popen referenced but not documented in Python 3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1306768936.07.0.714812479723.issue9382@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Its documentation in both 2.6 and 2.7 notes:
>
> Deprecated since version 2.6: This function is obsolete. 
> Use the subprocess module.

The deprecation should be removed from Python 2.7: os.popen() will not be removed from Python 2 because 2.7 is the last major version of the 2.x branch. And os.popen() will stay in Python 3: see #6490 and the Guido's message
http://bugs.python.org/issue6490#msg90572

> If it was decided to keep os.popen alive, it *should* be 
> documented in 3.x

Yes, os.popen() must be documented in Python 3. Do you want to write a patch to restore the doc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9382>
_______________________________________

From report at bugs.python.org  Mon May 30 17:27:13 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 30 May 2011 15:27:13 +0000
Subject: [issue12216] future imports change the reporting of syntaxerrors
In-Reply-To: <1306767297.7.0.76540444561.issue12216@psf.upfronthosting.co.za>
Message-ID: <1306769233.0.0.175857216097.issue12216@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually anything before the last statement will cause this

>>> compile("\ndef foo(", '', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 2
    def foo(
           ^
SyntaxError: invalid syntax

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12216>
_______________________________________

From report at bugs.python.org  Mon May 30 17:29:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 15:29:53 +0000
Subject: [issue9382] os.popen referenced but not documented in Python 3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1306769393.4.0.525569669856.issue9382@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I suggest we move the discussion to #6490.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> os.popen documentation in 2.6 is probably wrong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9382>
_______________________________________

From report at bugs.python.org  Mon May 30 17:38:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 15:38:43 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306769923.75.0.0905485505254.issue12082@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Should the .pyc/.pyo file writing be disabled altogether
> if stat() and/or fstat() is not available.

If we cannot get the file modification time, .pyc/.pyo writing must be disabled. If your OS/libc/filesystem doesn't have fstat(), you don't have file modification, so no .pyc/.pyo write.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Mon May 30 17:40:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 15:40:09 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1306770009.64.0.382546052911.issue6490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

> The deprecations for os.popenN() are still fine, since those
> APIs are not used all that much, and I'm sure that no one can
> really remember what all the different versions do anyway :-)

That's good, because those functions are already gone in Python3 :)

Victor: did you notice that getoutput and friends call os.popen?

The one argument I can see for actually deprecating os.popen is that in general the os module functions are thin wrappers around the corresponding posix functions.  But that is only true in general, and os.popen was never a "thin" wrapper, at least on most platforms.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Mon May 30 17:45:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 15:45:13 +0000
Subject: [issue12217] Cross-link docs for faulthandler, traceback and pdb
In-Reply-To: <1306770313.4.0.799430970978.issue12217@psf.upfronthosting.co.za>
Message-ID: <1306770313.4.0.799430970978.issue12217@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

haypo suggested linking between traceback.print_tb and faulthandler.dump_traceback().  See also links between pdb and faulthandler could also be nice, if they explain briefly how the modules differ.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 137298
nosy: docs at python, eric.araujo, haypo
priority: normal
severity: normal
stage: needs patch
status: open
title: Cross-link docs for faulthandler, traceback and pdb
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12217>
_______________________________________

From report at bugs.python.org  Mon May 30 17:52:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 15:52:32 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1306770009.64.0.382546052911.issue6490@psf.upfronthosting.co.za>
Message-ID: <201105301752.26036.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor: did you notice that getoutput and friends call os.popen?

Yes, because I wrote a patch to call directly subprocess :-) => see the issue 
#10197. I don't want to remove os.popen() anymore, it's too much work for a 
minor gain (we will remove it in Python 4). But we can add a note in its 
documentation saying that the subprocess should be prefered.

> But that is only true in general, and os.popen was never
> a "thin" wrapper, at least on most platforms.

os.popen() was a thin wrapper in Python 2.x: posix.popen() was a wrapper of 
the popen() C function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Mon May 30 18:15:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 16:15:12 +0000
Subject: [issue12216] future imports change the reporting of syntaxerrors
In-Reply-To: <1306767297.7.0.76540444561.issue12216@psf.upfronthosting.co.za>
Message-ID: <E1QR57X-0001O2-0c@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset fefca6548732 by Benjamin Peterson in branch 'default':
don't restrict unexpected EOF errors to the first line (closes #12216)
http://hg.python.org/cpython/rev/fefca6548732

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12216>
_______________________________________

From report at bugs.python.org  Mon May 30 18:43:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 30 May 2011 16:43:43 +0000
Subject: =?utf-8?q?=5Bissue10449=5D_=E2=80=9Cos=2Eenviron_was_modified_by_test=5Fh?=
	=?utf-8?q?ttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1306773823.81.0.838184441765.issue10449@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From IRC: too late for 3.1.

----------
resolution:  -> out of date
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10449>
_______________________________________

From report at bugs.python.org  Mon May 30 18:44:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2011 16:44:29 +0000
Subject: [issue6490] os.popen documentation in 2.6 is probably wrong
In-Reply-To: <1247646939.28.0.091306950041.issue6490@psf.upfronthosting.co.za>
Message-ID: <1306773869.65.0.891894126304.issue6490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There were an awfully large number of pages of code for a thin wrapper.  Granted, half of that was probably os/2 support...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Mon May 30 18:47:32 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Mon, 30 May 2011 16:47:32 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306774052.9.0.710705202823.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

RE: comment msg137266 - thanks for responding, Alex - though
don't get misled by that wrapper script I wrote, though - I
ended up replacing it with a short "C" program, which I'll attach
after this comment.

RE: > I think Python is awesome ...

I think Python is awesome too - I've been programming with it for nearly
eight years now - but I HATE the modern propensity for replacing
perfectly OK "C" programs and shell scripts with Python , or any
other interpreter, "Just for the sake of it", 
- let's be clear what an interpreter or compiler's job is :
   it is to present the correct machine code to the computer for
   execution to perform a certain well defined task
. So I don't think an "interpreter script" is automatically, by
definition, preferable to a compiled executable.  And I don't
like significant white-space and PERL will always be my preferred
script interpreter, sorry Python, that's just the way it is .

I'm appending the "C" source python wrapper program that I use after this.

----------
Added file: http://bugs.python.org/file22196/python.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 18:48:09 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 30 May 2011 16:48:09 +0000
Subject: [issue10645] Remove egg-info files in stdlib
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1306774089.07.0.461566677122.issue10645@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am going to remove wsgiref.egg-info

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Mon May 30 18:49:35 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 30 May 2011 16:49:35 +0000
Subject: [issue12125] test_sysconfig fails on OpenIndiana because of
	test_packaging
In-Reply-To: <1305850130.9.0.945341477682.issue12125@psf.upfronthosting.co.za>
Message-ID: <1306774175.39.0.23216423143.issue12125@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I fixed it

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12125>
_______________________________________

From report at bugs.python.org  Mon May 30 18:50:48 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 30 May 2011 16:50:48 +0000
Subject: [issue12218] Removing wsgiref.egg-info
In-Reply-To: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>
Message-ID: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

I am removing that metadata info, since we're moving to PEP 376

----------
assignee: tarek
components: Library (Lib)
messages: 137306
nosy: tarek
priority: normal
severity: normal
status: open
title: Removing wsgiref.egg-info
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12218>
_______________________________________

From report at bugs.python.org  Mon May 30 18:51:19 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 30 May 2011 16:51:19 +0000
Subject: [issue10645] Remove egg-info files in stdlib
In-Reply-To: <1291712814.77.0.81787148742.issue10645@psf.upfronthosting.co.za>
Message-ID: <1306774279.75.0.294203522815.issue10645@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

see issue12218

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10645>
_______________________________________

From report at bugs.python.org  Mon May 30 18:57:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 16:57:00 +0000
Subject: [issue12218] Removing wsgiref.egg-info
In-Reply-To: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>
Message-ID: <E1QR5ly-0004Ns-MM@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset d615eb7bce33 by Tarek Ziade in branch 'default':
Issue 12218: Removing wsgiref.egg-info
http://hg.python.org/cpython/rev/d615eb7bce33

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12218>
_______________________________________

From report at bugs.python.org  Mon May 30 18:57:39 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 30 May 2011 16:57:39 +0000
Subject: [issue12218] Removing wsgiref.egg-info
In-Reply-To: <1306774248.3.0.608189461621.issue12218@psf.upfronthosting.co.za>
Message-ID: <1306774659.95.0.116093903124.issue12218@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12218>
_______________________________________

From report at bugs.python.org  Mon May 30 19:08:01 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Mon, 30 May 2011 17:08:01 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306775281.37.0.528495068486.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

so I can do:

$ setarch i686 
$ strace -s8192  -e trace=execve /usr/bin/python
execve("/usr/bin/python", ["/usr/bin/python"], [/* 65 vars */]) = 0
execve("/usr/bin//32/python", ["/usr/bin//32/python"], [/* 66 vars */]) = 0
[ Process PID=3559 runs in 32 bit mode. ]
Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ strace -s8192  -e trace=execve /usr/bin/python2.7
execve("/usr/bin/python2.7", ["/usr/bin/python2.7"], [/* 65 vars */]) = 0
execve("/usr/bin//32/python2.7", ["/usr/bin//32/python2.7"], [/* 66 vars */]) = 0
[ Process PID=3571 runs in 32 bit mode. ]
Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

This is necessary because the 32-bit /usr/bin/32/python*'s PYTHONHOME is /usr/lib32/python2.7 , where 32-bit shared library python modules
are installed under lib-dynload/, while the native 64-bit's /usr/bin/python2.7's PYTHONHOME is /usr/lib64/python2.7 which has 64-bit 
libraries in lib-dynload . The 32-bit python uses /etc/32/ as its
$SYSCONFDIR .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 19:23:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 30 May 2011 17:23:48 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <201105300000.05934.victor.stinner@haypocalc.com>
Message-ID: <BANLkTi=dORP0=eWtPs2cfV_i1jshjCsigw@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> support.linux_version() may be changed for requires_linux_version(2, 6, 27),
>
> but linux_version() is always used in tests to check the Linux version.
> requires_linux_version() would only raise a SkipTest if the OS is Linux and
> if
> the kernel is lesser than the specified version.
>

See the patch attached.

> By the way, I like the new os.pipe2() function! You may want to document it
> in
> the "What's new in Python 3.3" doc (just mention the new function, the
> document will be rephrased later).
>

Sure, where is this document?

----------
Added file: http://bugs.python.org/file22197/support_linux_version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________
-------------- next part --------------
diff -r f73d80d0ba44 Lib/test/support.py
--- a/Lib/test/support.py	Mon May 30 11:15:05 2011 -0500
+++ b/Lib/test/support.py	Mon May 30 19:21:14 2011 +0200
@@ -291,13 +291,17 @@
             msg = "Use of the `%s' resource not enabled" % resource
         raise ResourceDenied(msg)
 
-def linux_version():
-    try:
-        # platform.release() is something like '2.6.33.7-desktop-2mnb'
-        version_string = platform.release().split('-')[0]
-        return tuple(map(int, version_string.split('.')))
-    except ValueError:
-        return 0, 0, 0
+def requires_linux_version(*min_version):
+    if sys.platform.startswith('linux'):
+        try:
+            # platform.release() is something like '2.6.33.7-desktop-2mnb'
+            version_string = platform.release().split('-')[0]
+            version = tuple(map(int, version_string.split('.')))
+            if version < min_version:
+                raise unittest.SkipTest("Linux kernel %s or higher required" %
+                                        ".".join(map(str, min_version)))
+        except ValueError:
+            pass
 
 HOST = 'localhost'
 
diff -r f73d80d0ba44 Lib/test/test_posix.py
--- a/Lib/test/test_posix.py	Mon May 30 11:15:05 2011 -0500
+++ b/Lib/test/test_posix.py	Mon May 30 19:21:14 2011 +0200
@@ -310,10 +310,7 @@
 
     @unittest.skipUnless(hasattr(os, 'O_CLOEXEC'), "needs os.O_CLOEXEC")
     def test_oscloexec(self):
-        version = support.linux_version()
-        if sys.platform == 'linux2' and version < (2, 6, 23):
-            self.skipTest("Linux kernel 2.6.23 or higher required, "
-                          "not %s.%s.%s" % version)
+        support.requires_linux_version(2, 6, 23)
         fd = os.open(support.TESTFN, os.O_RDONLY|os.O_CLOEXEC)
         self.addCleanup(os.close, fd)
         self.assertTrue(fcntl.fcntl(fd, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
@@ -480,10 +477,7 @@
 
     @unittest.skipUnless(hasattr(os, 'pipe2'), "test needs os.pipe2()")
     def test_pipe2(self):
-        version = support.linux_version()
-        if sys.platform == 'linux2' and version < (2, 6, 27):
-            self.skipTest("Linux kernel 2.6.27 or higher required, "
-                          "not %s.%s.%s" % version)
+        support.requires_linux_version(2, 6, 27)
         self.assertRaises(TypeError, os.pipe2, 'DEADBEEF')
         self.assertRaises(TypeError, os.pipe2, 0, 0)
 
diff -r f73d80d0ba44 Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Mon May 30 11:15:05 2011 -0500
+++ b/Lib/test/test_socket.py	Mon May 30 19:21:14 2011 +0200
@@ -1024,10 +1024,7 @@
 
     if hasattr(socket, "SOCK_NONBLOCK"):
         def testInitNonBlocking(self):
-            v = support.linux_version()
-            if v < (2, 6, 28):
-                self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                              % ".".join(map(str, v)))
+            support.requires_linux_version(2, 6, 28)
             # reinit server socket
             self.serv.close()
             self.serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM |
@@ -2002,10 +1999,7 @@
 @unittest.skipUnless(fcntl, "module fcntl not available")
 class CloexecConstantTest(unittest.TestCase):
     def test_SOCK_CLOEXEC(self):
-        v = support.linux_version()
-        if v < (2, 6, 28):
-            self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                          % ".".join(map(str, v)))
+        support.requires_linux_version(2, 6, 28)
         with socket.socket(socket.AF_INET,
                            socket.SOCK_STREAM | socket.SOCK_CLOEXEC) as s:
             self.assertTrue(s.type & socket.SOCK_CLOEXEC)
@@ -2024,10 +2018,7 @@
             self.assertEqual(s.gettimeout(), None)
 
     def test_SOCK_NONBLOCK(self):
-        v = support.linux_version()
-        if v < (2, 6, 28):
-            self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                          % ".".join(map(str, v)))
+        support.requires_linux_version(2, 6, 28)
         # a lot of it seems silly and redundant, but I wanted to test that
         # changing back and forth worked ok
         with socket.socket(socket.AF_INET,

From report at bugs.python.org  Mon May 30 19:34:08 2011
From: report at bugs.python.org (Alex Leach)
Date: Mon, 30 May 2011 17:34:08 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306776848.93.0.254746590347.issue11946@psf.upfronthosting.co.za>


Alex Leach <beamesleach at gmail.com> added the comment:

Hey Jason,

Thanks for replying so quickly, and on a bank holiday! :)
This has completely diverged from the original bug, but whatever..

Thanks for the C wrapper too! It's not appropriate for my build environment, and I know no C, having only got so far as writing a hello world program with it, so I'll probably stick with my bash wrapper script for now.
Currently re-compiling python2.7.1 to support i686 machines. The first build wasn't allowing me to compile numpy with the supplied atlas libraries, failing to pick up the extension .so.3 / .so.3.0 which I think has something to do with position independent code, so I'm recompiling this 32 bit python with the following commands:-
$ export CFLAGS="-O2 -fPIC"
$ export CXXFLAGS=$CFLAGS
$ OPT=-m32 LDFLAGS=-m32 ./configure --prefix=$HOME/32

Does that seem sensible to you??
The relevant part of my bash wrapper script (for sun grid engine) is then something like:-

#!/bin/bash
if [[ "`uname -m`" = "x86_64" ]] ; then
        export PYTHONHOME=$HOME/
else   
        echo "arch = `uname -m`"
        export PYTHONHOME=$HOME/32
fi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 19:37:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 30 May 2011 17:37:39 +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: <1306777059.44.0.510762881042.issue11975@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well (speaking as the Sphinx developer here), I view it as legacy behavior that type does not matter for non-intersphinx linking.

So the intersphinx behavior is the "correct" one, but we can't change the other now because of compatibility.

But (speaking as a Python doc person), I am -0 on changing :func: to :class: when we change these types to be documented as classes: it adds no value at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 19:55:04 2011
From: report at bugs.python.org (Marc Sibson)
Date: Mon, 30 May 2011 17:55:04 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1306778104.57.0.151194615022.issue10772@psf.upfronthosting.co.za>


Marc Sibson <sibson at gmail.com> added the comment:

issue10772.patch2: document help and count actions in Doc/library/argparse.rst

----------
Added file: http://bugs.python.org/file22198/issue10772.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10772>
_______________________________________

From report at bugs.python.org  Mon May 30 20:00:43 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Mon, 30 May 2011 18:00:43 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306778443.42.0.0928986334988.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

RE: msg137311 : Alex - you wrote :
> I'm recompiling this 32 bit python with the following commands:-
> $ export CFLAGS="-O2 -fPIC"
> $ export CXXFLAGS=$CFLAGS
> $ OPT=-m32 LDFLAGS=-m32 ./configure --prefix=$HOME/32
> Does that seem sensible to you??

Well, it depends on the output of these commands on your system :
$ gcc -print-search-dirs | grep '^libraries'
libraries: =/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/

$ gcc -print-multi-os-directory
../lib64

Your C compiler should be appending an option such as :
  '--dynamic-linker=/lib32/ld-linux.so.2 -rpath /usr/lib32:/lib32' 
to it's ld(1) command line - if you have C compilation problems, look
at the output of adding '--verbose' to the $CFLAGS you
gave and looking at what options are used by gcc's 'collect' phase:
$ gcc -o /tmp/t ~jason/t.c --verbose 2>&1 | tail -n 2
COLLECT_GCC_OPTIONS='-o' '/tmp/t' '-v' '-mtune=k8' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /tmp/t /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtbegin.o -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. /tmp/ccoSip93.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtend.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o

$ gcc -m32 -o /tmp/t ~jason/t.c --verbose 2>&1 | tail -n 2
COLLECT_GCC_OPTIONS='-m32' '-o' '/tmp/t' '-v' '-mtune=i686' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib32/ld-linux.so.2 -o /tmp/t /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crt1.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crti.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/crtbegin.o -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. /tmp/ccZzwAuw.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/crtend.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crtn.o

'~jason/t.c' is just :
$ echo -e '#include <stdio.h>\nint main(){ printf("hello world!\n");}' > ~jason/t.c




If you are on a RedHat derived system, where /lib/ld-linux.so.2 is
32-bit ,  you should be OK;  if, however, you are on a Gentoo
derived or "my style" system, your

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 20:02:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 30 May 2011 18:02:05 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1306778525.99.0.947802293794.issue12021@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The patch looks good to me.
In your test, you don't explicitely close the mmap object: it's not a problem with CPython since it will get unmmapped, and the file descriptor - if it's a file-backed mapping - will get closed, as soon as it gets out of scope, but it would be cleaner to close it explicitely with something like self.addCleanup(m.close).

----------
nosy: +charles-francois.natali
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Mon May 30 20:23:57 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Mon, 30 May 2011 18:23:57 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306779837.96.0.08719361757.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

Oops, cut myself off mid-sentence in that previous comment ... AIWS :

If you are on a RedHat derived system, where /lib/ld-linux.so.2 is
32-bit ,  you should be OK;  if, however, you are on a Gentoo
derived or "my style" system, you need to make sure your 
gcc is compiled with '--enable-multilib' and '--enable-targets=all',
as mine is , and that you have applied something like this patch
to gcc's gcc/config/i386/linux*.h files:

$ gendiff gcc/config '~'
diff -up gcc/config/i386/linux.h~ gcc/config/i386/linux.h
--- gcc/config/i386/linux.h~    2011-01-14 18:45:06.000000000 +0000
+++ gcc/config/i386/linux.h     2011-04-05 22:17:10.000000000 +0100
@@ -92,7 +92,7 @@ along with GCC; see the file COPYING3.

 /* These macros may be overridden in k*bsd-gnu.h and i386/k*bsd-gnu.h. */
 #define LINK_EMULATION "elf_i386"
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER "/lib32/ld-linux.so.2"

 #undef  ASM_SPEC
 #define ASM_SPEC \
diff -up gcc/config/i386/linux64.h~ gcc/config/i386/linux64.h
--- gcc/config/i386/linux64.h~  2011-03-02 22:35:36.000000000 +0000
+++ gcc/config/i386/linux64.h   2011-04-05 22:17:33.000000000 +0100
@@ -62,7 +62,7 @@ see the files COPYING3 and COPYING.RUNTI
    When the -shared link option is used a final link is not being
    done.  */

-#define GLIBC_DYNAMIC_LINKER32 "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER32 "/lib32/ld-linux.so.2"
 #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"

 #if TARGET_64BIT_DEFAULT

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 20:27:17 2011
From: report at bugs.python.org (Jason Vas Dias)
Date: Mon, 30 May 2011 18:27:17 +0000
Subject: [issue11946] 2.7.1 'test_commands' build test fails
In-Reply-To: <1303996577.19.0.414783548964.issue11946@psf.upfronthosting.co.za>
Message-ID: <1306780037.5.0.593588188174.issue11946@psf.upfronthosting.co.za>


Jason Vas Dias <jason.vas.dias at gmail.com> added the comment:

The alternative is to use a "GCC Spec File" , such as
that printed by 
 $ gcc -dumpspecs

Here is one such I've used in the past to overcome similar problems:

$ cat /home/jason/local32.spec
*lib:
+ -lc_nonshared

*startfiles:
+ /lib32/crti.o

*endfiles:
+ /lib32/crtn.o

*link:
+ -dynamic-linker /usr/local/lib%{!m32:64}%{m32:32}/ld-linux-%{!m32:x86_64}%{m32:i386}.so.2 -L/usr/local/lib/gcc-lib/%{!m32:x86_64-redhat-linux}%{m32:i386-redhat-linux}/4/%{m32:32} -L/usr/local/lib/%{!m32:64}%{m32:32} -R/usr/local/lib/gcc/%{!m32:x86_64-redhat-linux}%{m32:i386-redhat-linux}/4 -R/usr/local/lib%{m32:32}%{!m32:64} -R/usr/local/lib

*cpp:
+ -isystem /usr/local/include

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11946>
_______________________________________

From report at bugs.python.org  Mon May 30 20:46:01 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 30 May 2011 18:46:01 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1306781161.41.0.0849422879675.issue12021@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Thanks for the comments. I attached a new patch that uses self.addCleanup(m.close), and also adds a versionchanged directive to the docs.

----------
Added file: http://bugs.python.org/file22199/mmap_read_all_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Mon May 30 20:50:43 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 30 May 2011 18:50:43 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1306769923.75.0.0905485505254.issue12082@psf.upfronthosting.co.za>
Message-ID: <20110530185040.GA1724@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

STINNER Victor wrote:
> If we cannot get the file modification time, .pyc/.pyo writing must be disabled. If your OS/libc/filesystem doesn't have fstat(), you don't have file modification, so no .pyc/.pyo write.

Should I go on and write a patch? Any hints on how this code path (of
not writing .pyc/.pyo because of missing stat() and fstat()) could be
tested?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Mon May 30 21:15:17 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 30 May 2011 19:15: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: <1306782917.23.0.020073040382.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

@Eric: ok, I was just asking given the "unusual" situation 2.7 is (i.e. a very long support series), but it's perfectly fine not to backport the feature.

@Charles-Fran?ois: I changed a bit the logic: I check for 'None' at first, since it signals that we don't want to change the uid/gid, and then I recheck for None after _get_uid/gid, and only there raise a ValueError (is there a better exception for cases like this?) - what do you think about it?

@?ric: re rewrap: I kinda find that almost every core dev has his opinion on this :) some don't want to rewrap, others are fine if you're touching that paragraph, and so on. Anyhow, to be on the safe-side, I un-rewrapped the first paragraph of os.chown().

@Gregory: I'd like to first concentrate on the "single path" function, then we'll look at the "tree" version.

Thanks a lot to everyone for the review/comment/inspiration: attached you can find the updated patch. If something still needs a fix, I'd be happy to work on it.

----------
Added file: http://bugs.python.org/file22200/shutil_chown-default-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Mon May 30 21:27:39 2011
From: report at bugs.python.org (Jonas H.)
Date: Mon, 30 May 2011 19:27:39 +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: <1306783659.52.0.031615680466.issue11975@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

> So the intersphinx behavior is the "correct" one, but we can't change the other now because of compatibility.

Could you be convinced to use that legacy behaviour for intersphinx, too? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11975>
_______________________________________

From report at bugs.python.org  Mon May 30 21:40:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 19:40:06 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <BANLkTi=dORP0=eWtPs2cfV_i1jshjCsigw@mail.gmail.com>
Message-ID: <201105302140.00131.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> See the patch attached.

I like your patch, it removes many duplicate code :-)

Some comments:
 - I don't like an if surrounding the whole function, I prefer "if not ...: 
return" to avoid the (useless) indentation. Well, it's my coding style, do as 
you want.
 - You should add docstrings. Something like "Raise a SkipTest if the OS is 
Linux and the kernel version if lesser than min_version. For example, 
support.requires_linux_version(2, 6, 28) raises a SkipTest if the version is 
lesser than 2.6.28."
 - You should move the "if version < ..." outside the try/except ValueError

+            # platform.release() is something like '2.6.33.7-desktop-2mnb'
+            version_string = platform.release().split('-')[0]

Dummy micro-optimization: .split('-', 1)[0] or .partition('-')[0] is maybe 
better than .split('-')[0].

> > By the way, I like the new os.pipe2() function! You may want to document
> > it in
> > the "What's new in Python 3.3" doc (just mention the new function, the
> > document will be rephrased later).
> 
> Sure, where is this document?

Doc/whatsnew/3.3.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Mon May 30 22:09:19 2011
From: report at bugs.python.org (Josh Triplett)
Date: Mon, 30 May 2011 20:09:19 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306786159.54.0.696543587346.issue12082@psf.upfronthosting.co.za>


Josh Triplett <josh at joshtriplett.org> added the comment:

Given that GRUB doesn't support writing to filesystems at all, I already have to set Py_DontWriteBytecodeFlag, so disabling .pyc/.pyo entirely would work fine for my use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Mon May 30 22:12:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 20:12:29 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306786349.26.0.824904809149.issue12082@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Should I go on and write a patch?

Yes please, write a patch, I will review it.

To emulate a system without stat or fstat, you may use:
#define fstat dont_have_fstat
#define stat dont_have_stat

The link will fail if the code still refer to fstat() or stat().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Mon May 30 22:54:41 2011
From: report at bugs.python.org (Herm Fischer)
Date: Mon, 30 May 2011 20:54:41 +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: <1306788881.55.0.171400893605.issue12219@psf.upfronthosting.co.za>


New submission from Herm Fischer <fischer at markv.com>:

tkinter.filedialog.askopenfilename works fine on the Windows builds of Python 3.1.

However on Python 3.2 (Windows builds via Active State), this dialog comes up with the old Windows XT style on Windows 7 (missing navigation pane) and the dialog is not resizable (it was resizable in Python 3.1).

Application users are inconvenienced, trouble opening long file names.

Is there a work-around in Python 3.2?

----------
components: Tkinter
files: python31-correct-filedialog.png
messages: 137325
nosy: hfischer
priority: normal
severity: normal
status: open
title: tkinter.filedialog.askopenfilename XT dialog on Windows 7
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22201/python31-correct-filedialog.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12219>
_______________________________________

From report at bugs.python.org  Mon May 30 22:55:55 2011
From: report at bugs.python.org (Herm Fischer)
Date: Mon, 30 May 2011 20:55:55 +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: <1306788955.66.0.724094713539.issue12219@psf.upfronthosting.co.za>


Changes by Herm Fischer <fischer at markv.com>:


Added file: http://bugs.python.org/file22202/python32-wrong-filedialog.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12219>
_______________________________________

From report at bugs.python.org  Mon May 30 22:57:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 20:57:33 +0000
Subject: [issue12171] Reset method of the incremental encoders of CJK
	codecs	calls the decoder reset function
In-Reply-To: <1306272610.09.0.544983510559.issue12171@psf.upfronthosting.co.za>
Message-ID: <E1QR9Wm-0005Ml-7l@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 61aaec67b521 by Victor Stinner in branch 'default':
Close #12171: IncrementalEncoder.reset() of CJK codecs (multibytecodec) calls
http://hg.python.org/cpython/rev/61aaec67b521

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12171>
_______________________________________

From report at bugs.python.org  Mon May 30 22:58:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 20:58:25 +0000
Subject: [issue12089] regrtest.py doesn't check for unexpected output anymore?
In-Reply-To: <1305558844.58.0.490167239537.issue12089@psf.upfronthosting.co.za>
Message-ID: <E1QR9Xc-0005QD-F8@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6051f2c93163 by Victor Stinner in branch 'default':
Close #12089: Remove outdated and unused code from regrtest.
http://hg.python.org/cpython/rev/6051f2c93163

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12089>
_______________________________________

From report at bugs.python.org  Mon May 30 23:04:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 21:04:23 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc or make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <E1QR9dN-0005rS-NY@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 5548197d1f22 by Victor Stinner in branch 'default':
Close #12028: Make threading._get_ident() public, rename it to
http://hg.python.org/cpython/rev/5548197d1f22

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 30 23:06:13 2011
From: report at bugs.python.org (Herm Fischer)
Date: Mon, 30 May 2011 21:06:13 +0000
Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute
	value field
In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za>
Message-ID: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za>


New submission from Herm Fischer <fischer at markv.com>:

Minidom raises an exception if there's a space anywhere in the URI of an xmlns, but it is legal (but terrible practice) to have spaces in URIs.  I think this should work or politely raise a syntax error.  E.g., this fails:  xmlns:abc="http:abc.com/de f g/hi/j k".

The attachment xml file from an end user has this xmlns:

  xmlns:verrels=" http://xbrl.org/2010/versioning-relationship-sets"

which causes minidom to raise a ValueError exception, instead of a sensible syntax error message.  

The relevant python code is expabuilder.py, method _parse_ns_name, which does not have an elif for len(parts) != 2 (to raise a syntax error which identifies the bad construct).

----------
components: XML
files: test.xml
messages: 137329
nosy: hfischer
priority: normal
severity: normal
status: open
title: minidom xmlns not handling spaces in xmlns attribute value field
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file22203/test.xml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12220>
_______________________________________

From report at bugs.python.org  Mon May 30 23:09:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 21:09:09 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1306789749.72.0.435153334274.issue8533@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The original issue (use backslashreplace for stdout in regrtest) is now fixed, and so I closed it.

@ocean-city: Can you please open a new issue for unittest? (for py3k_also_no_unicode_error_on_direct_test_run.patch)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Mon May 30 23:13:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 21:13:23 +0000
Subject: [issue9738] Document the encoding of functions bytes arguments of the
	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1306790003.88.0.717420337332.issue9738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here is an interesting case for your collection: PyDict_GetItemString.

It's easier to guess the encoding of such function: Python 3 always use UTF-8, but yes, the encoding should be documented.

I documented many functions, directly in the header files, and sometimes also in the reST documentation.

I close this issue because I consider it as done. If you would like to document the encoding of some specific functions, please open new issues.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9738>
_______________________________________

From report at bugs.python.org  Mon May 30 23:21:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 21:21:38 +0000
Subject: [issue10616] Change PyObject_AsCharBuffer() error message
In-Reply-To: <1291394615.71.0.46026990965.issue10616@psf.upfronthosting.co.za>
Message-ID: <E1QR9u5-00076R-Dh@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 7ed75bb4f37c by Victor Stinner in branch 'default':
Close #10616: mention bytes and bytearray in PyObject_AsCharBuffer() error
http://hg.python.org/cpython/rev/7ed75bb4f37c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10616>
_______________________________________

From report at bugs.python.org  Mon May 30 23:23:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 21:23:59 +0000
Subject: [issue12028] threading._get_ident(): remove it in the doc or make it
	public
In-Reply-To: <1304763885.69.0.0673307272.issue12028@psf.upfronthosting.co.za>
Message-ID: <E1QR9wM-0007BV-2w@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6387aa6b496d by Victor Stinner in branch 'default':
Issue #12028: fix NEWS entry
http://hg.python.org/cpython/rev/6387aa6b496d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12028>
_______________________________________

From report at bugs.python.org  Mon May 30 23:45:57 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 May 2011 21:45:57 +0000
Subject: [issue4833] Explicit directories for zipfiles
In-Reply-To: <1231088968.72.0.101458538333.issue4833@psf.upfronthosting.co.za>
Message-ID: <1306791957.95.0.210800743213.issue4833@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/issue4833>
_______________________________________

From report at bugs.python.org  Mon May 30 23:47:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 21:47:16 +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: <E1QRAIt-0000Fo-DC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 3b1b06570cf9 by Victor Stinner in branch '2.7':
Issue #12016: my_fgets() now always clears errors before calling fgets(). Fix
http://hg.python.org/cpython/rev/3b1b06570cf9

New changeset de07f90ef45c by Victor Stinner in branch '3.2':
Issue #12016: my_fgets() now always clears errors before calling fgets(). Fix
http://hg.python.org/cpython/rev/de07f90ef45c

New changeset deb6e7859211 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12016: my_fgets() now always clears errors before calling
http://hg.python.org/cpython/rev/deb6e7859211

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Mon May 30 23:48:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 21:48:11 +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: <1306792091.37.0.318749846956.issue12016@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg137334

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Mon May 30 23:48:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 21:48:37 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1306792117.58.0.802442135903.issue1195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, I specified the wrong issue number in my commits :-/

New changeset 3b1b06570cf9 by Victor Stinner in branch '2.7':
Issue #12016: my_fgets() now always clears errors before calling fgets(). Fix
http://hg.python.org/cpython/rev/3b1b06570cf9

New changeset de07f90ef45c by Victor Stinner in branch '3.2':
Issue #12016: my_fgets() now always clears errors before calling fgets(). Fix
http://hg.python.org/cpython/rev/de07f90ef45c

New changeset deb6e7859211 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12016: my_fgets() now always clears errors before calling
http://hg.python.org/cpython/rev/deb6e7859211

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Mon May 30 23:50:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 21:50:43 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <E1QRAME-0000Yi-J7@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset b40dac6390a9 by Victor Stinner in branch '2.7':
Issue #1195: fix the issue number of the NEWS entry
http://hg.python.org/cpython/rev/b40dac6390a9

New changeset d780ca579e6f by Victor Stinner in branch '3.2':
Issue #1195: fix the issue number of the NEWS entry
http://hg.python.org/cpython/rev/d780ca579e6f

New changeset 29e61c4ba59f by Victor Stinner in branch 'default':
(Merge 3.2) Issue #1195: fix the issue number of the NEWS entry
http://hg.python.org/cpython/rev/29e61c4ba59f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Mon May 30 23:51:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 21:51:50 +0000
Subject: [issue1195] Problems on Linux with Ctrl-D and Ctrl-C during raw_input
In-Reply-To: <1190630936.13.0.318924236509.issue1195@psf.upfronthosting.co.za>
Message-ID: <1306792310.98.0.0128966721801.issue1195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The patch still does not handle the case where the eof indicator
> is already set when calling raw_input. My original patch does.

I commited your original patch but I kept mine because it doesn't hurt to clear the error on EOF at exit. Reopen the issue if it still doesn't work in all cases.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue May 31 00:03:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2011 22:03:18 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <E1QRAYO-0001DE-Nu@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 6c6923a406df by Victor Stinner in branch '2.7':
Issue #12057: Add tests for ISO 2022 codecs
http://hg.python.org/cpython/rev/6c6923a406df

New changeset 2a313ceaf17c by Victor Stinner in branch '3.2':
Issue #12057: Add tests for ISO 2022 codecs
http://hg.python.org/cpython/rev/2a313ceaf17c

New changeset 1a9ccb5bef27 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #12057: Add tests for ISO 2022 codecs
http://hg.python.org/cpython/rev/1a9ccb5bef27

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Tue May 31 00:05:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 22:05:14 +0000
Subject: [issue12057] HZ codec has no test
In-Reply-To: <1305118918.67.0.692946410577.issue12057@psf.upfronthosting.co.za>
Message-ID: <1306793114.21.0.798895641351.issue12057@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We have know tests for some ISO 2022 codecs and the HZ codec, it's much better!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12057>
_______________________________________

From report at bugs.python.org  Tue May 31 00:12:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2011 22:12:22 +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: <1306793542.58.0.912515296766.issue12016@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

- I added tests for the HZ codec and some ISO 2022 codecs: #12057
 - I fixed IncrementalEncoder.encode() (of multibytecodec ): #12100
 - I fixed IncrementalEncoder.reset() (of multibytecodec): #12171

I can now work confidently on this issue. I will try to patch all CJK decoders to only replace 1 invalid byte by U+FFFD (and not 2, 3 or 4 bytes) and try to write a test for each case (each byte sequence generating a different error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12016>
_______________________________________

From report at bugs.python.org  Tue May 31 00:51:08 2011
From: report at bugs.python.org (Jean-Marc Saffroy)
Date: Mon, 30 May 2011 22:51:08 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
	single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1306795868.39.0.0448563115883.issue11416@psf.upfronthosting.co.za>


Jean-Marc Saffroy <saffroy at gmail.com> added the comment:

Additional patch for docstrings and documentation. Applies on top of previous patch.

----------
Added file: http://bugs.python.org/file22204/netrc-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Tue May 31 01:24:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 May 2011 23:24:57 +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: <1306797897.21.0.360091669947.issue12219@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

If the problem is with an ActiveState distribution of Python 3.2, you should probably be asking this on the ActiveState forums.

----------
nosy: +brian.curtin, loewis, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12219>
_______________________________________

From report at bugs.python.org  Tue May 31 01:41:53 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 May 2011 23:41:53 +0000
Subject: [issue12220] minidom xmlns not handling spaces in xmlns attribute
	value field
In-Reply-To: <1306789573.92.0.875996944294.issue12220@psf.upfronthosting.co.za>
Message-ID: <1306798913.09.0.127188772615.issue12220@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12220>
_______________________________________

From report at bugs.python.org  Tue May 31 01:42:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 May 2011 23:42:07 +0000
Subject: [issue11612] xml.dom.minidom fail to parse SVG file.
In-Reply-To: <1300600053.35.0.927050616565.issue11612@psf.upfronthosting.co.za>
Message-ID: <1306798927.69.0.129002564071.issue11612@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Issue12220 also addresses this problem in somewhat more detail.  Consolidating this issue with that one.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> minidom xmlns not handling spaces in xmlns attribute value field

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11612>
_______________________________________

From report at bugs.python.org  Tue May 31 01:55:10 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 May 2011 23:55:10 +0000
Subject: [issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than
	multiprocessing.Pool.map() for fast function argument
In-Reply-To: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>
Message-ID: <1306799710.04.0.484345624228.issue11271@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11271>
_______________________________________

From report at bugs.python.org  Tue May 31 03:43:23 2011
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 31 May 2011 01:43:23 +0000
Subject: [issue12200] bdist_wininst install_script not run on uninstall
In-Reply-To: <1306548527.55.0.138367912737.issue12200@psf.upfronthosting.co.za>
Message-ID: <1306806203.21.0.164519502133.issue12200@psf.upfronthosting.co.za>


Changes by Mark Hammond <skippy.hammond at gmail.com>:


----------
assignee: tarek -> mhammond
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file22205/issue12200.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12200>
_______________________________________

From report at bugs.python.org  Tue May 31 05:08:52 2011
From: report at bugs.python.org (Brian May)
Date: Tue, 31 May 2011 03:08:52 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1306811332.95.0.283776934259.issue6560@psf.upfronthosting.co.za>


Brian May <brian at microcomaustralia.com.au> added the comment:

Have tested my code with this patch, the recvmsg(...) call seems to work fine.

Also had a half-hearted attempt at porting to Python 2.7, but didn't get past compiling, the code requires BEGIN_SELECT_LOOP and END_SELECT_LOOP macros that aren't defined in Python 2.7 - I tried copying the definitions from Python 3.3, but that didn't work either. Not sure if it is worth the effort if Python 2.7 is closed to new features.

Brian May

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue May 31 07:20:25 2011
From: report at bugs.python.org (Herm Fischer)
Date: Tue, 31 May 2011 05:20:25 +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: <1306819225.12.0.877610460231.issue12219@psf.upfronthosting.co.za>


Herm Fischer <fischer at markv.com> added the comment:

Now also posted to http://bugs.activestate.com/show_bug.cgi?id=90234

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12219>
_______________________________________

From report at bugs.python.org  Tue May 31 10:46:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 31 May 2011 08:46:37 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1304711654.25.0.661798385399.issue12021@psf.upfronthosting.co.za>
Message-ID: <1306831597.46.0.438111858591.issue12021@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I noticed that RawIOBase.read, TextIOBase.read, etc also accept None as the argument, treating it as -1. Should this be implemented, too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Tue May 31 10:47:43 2011
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 31 May 2011 08:47:43 +0000
Subject: [issue12221] segfaults with unexpanded $Revision$ id's in release
	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

Modules/pyexpat.c (get_version_string) has:

static PyObject *
get_version_string(void)
{
    static char *rcsid = "$Revision$";
    char *rev = rcsid;
    int i = 0;

    while (!isdigit(Py_CHARMASK(*rev)))
        ++rev;

which segfaults, or has unexpected results. -O2 builds don't show the segfaults, but at least debug builds on sparc, ARM, powerpc, m68k.

>>> pyexpat.__version__
'0\x05'

seen with all the current release candidates for 2.7.2, 3.1.4 and 3.2.1
2.5.6 and 2.6.7 don't have this issue.

other occurrences:

./setup.py:__version__ = "$Revision$"
./Demo/scripts/newslist.py:# Newslist  $Revision$
./Demo/scripts/newslist.py:rcsrev = '$Revision$'
./configure.in:AC_REVISION($Revision$)
./Tools/webchecker/websucker.py:__version__ = "$Revision$"
./Tools/webchecker/webchecker.py:__version__ = "$Revision$"
./Tools/world/world:__version__ = '$Revision$'
./Parser/asdl_c.py:        # Value of version: "$Revision$"
./Parser/Python.asdl:module Python version "$Revision$"
./Modules/pyexpat.c:    static char *rcsid = "$Revision$";
./Lib/tkinter/__init__.py:__version__ = "$Revision$"
./Lib/pickle.py:__version__ = "$Revision$"       # Code version
./Lib/xml/parsers/expat.py:__version__ = '$Revision$'
./Lib/pydoc.py:__version__ = "$Revision$"
./Lib/tarfile.py:__version__ = "$Revision$"

----------
components: Build
messages: 137347
nosy: benjamin.peterson, doko, georg.brandl
priority: release blocker
severity: normal
status: open
title: segfaults with unexpanded $Revision$ id's in release candidate tarballs
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12221>
_______________________________________

From report at bugs.python.org  Tue May 31 10:55:55 2011
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 31 May 2011 08:55:55 +0000
Subject: [issue12221] segfaults with unexpanded $Revision$ id's in release
	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <1306832155.39.0.297451598659.issue12221@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12221>
_______________________________________

From report at bugs.python.org  Tue May 31 11:16:13 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 31 May 2011 09:16:13 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

All actions in packaging.run need to respect a basic exit convention 0/1. 

This is important because pysetup will be used in automated scripts so the caller needs to know wether the call failed or succedeed. 

Example: pysetup install project => sys,exit(0 or 1)

----------
assignee: tarek
components: Distutils2
messages: 137348
nosy: alexis, eric.araujo, tarek
priority: high
severity: normal
status: open
title: All pysetup commands should respect exit codes
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12222>
_______________________________________

From report at bugs.python.org  Tue May 31 11:27:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 May 2011 09:27:50 +0000
Subject: [issue12221] segfaults with unexpanded $Revision$ id's in release
	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <1306834070.21.0.289273079334.issue12221@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

See also: Issue 11439

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12221>
_______________________________________

From report at bugs.python.org  Tue May 31 11:40:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 May 2011 09:40:24 +0000
Subject: [issue11505] string.py increased test coverage
In-Reply-To: <1300131460.79.0.278218518064.issue11505@psf.upfronthosting.co.za>
Message-ID: <E1QRLR1-0005un-Dj@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset f1a213d034af by Nick Coghlan in branch 'default':
Tidy up the additional string module tests added at the Pycon sprints (closes #11505)
http://hg.python.org/cpython/rev/f1a213d034af

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11505>
_______________________________________

From report at bugs.python.org  Tue May 31 11:42:25 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Tue, 31 May 2011 09:42:25 +0000
Subject: [issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than
	multiprocessing.Pool.map() for fast function argument
In-Reply-To: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>
Message-ID: <1306834945.03.0.935253696094.issue11271@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

On my crappy computer, ProcessPoolExecutor.map adds <3ms of added execution time per call using your test framework.

What is your use case where that is too much?

That being said, I don't have any objections to making improvements.

If you want to pursue this, could you attach a working map_comprison.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11271>
_______________________________________

From report at bugs.python.org  Tue May 31 11:42:55 2011
From: report at bugs.python.org (Vladimir M.)
Date: Tue, 31 May 2011 09:42:55 +0000
Subject: [issue12223] Datamodel documentation page: 'operator' where 'operand'
	should be
In-Reply-To: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>
Message-ID: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>


New submission from Vladimir M. <mlvl.jr at gmail.com>:

The page at (http://docs.python.org/reference/datamodel.html) says:
"In x * y, if one operator is a sequence that implements sequence repetition".

Obviuosly, it should be changed to:
"In x * y, if one operand is a sequence that implements sequence repetition".

----------
assignee: docs at python
components: Documentation
messages: 137352
nosy: Vladimir.M., docs at python
priority: normal
severity: normal
status: open
title: Datamodel documentation page: 'operator' where 'operand' should be
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12223>
_______________________________________

From report at bugs.python.org  Tue May 31 11:45:42 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 31 May 2011 09:45:42 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1306835142.55.0.706736219486.issue12164@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I added a patch a few days ago. How does it look?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12164>
_______________________________________

From report at bugs.python.org  Tue May 31 11:54:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 May 2011 09:54:34 +0000
Subject: [issue11505] string.py increased test coverage
In-Reply-To: <1300131460.79.0.278218518064.issue11505@psf.upfronthosting.co.za>
Message-ID: <1306835674.12.0.132656902371.issue11505@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Some comments on the follow-up changes I just committed:

- It's an illustration of the fact that coverage data is only step 1 in improving tests.

- I added additional assertions regarding the error message contents to a couple of tests, and also verified that the formatting code correctly allowed AttributeError, KeyError and IndexError to escape to the calling code when using subfield lookup.

- I changed the names of several of the test methods to more accurately reflect what they were designed to test.

- I broke up the original string formatting tests into multiple test methods. This fit in better with the updated method names and helps with diagnosing any errors that do arise in the future, since the smaller test methods help localise any failures.

- complex white-box tests designed to exercise obscure error paths definitely benefit from comments explaining what they're trying to do, which is definitely the case for the new test in test_pep292 which required an appropriately crafted template pattern

- I adjusted some of the new test methods to follow the same naming conventions as similar tests that were already in the test cases

Still, thanks to Alicia for the original patch and Jerome for picking up on the error in the vformat recursion limit test. Even if the final code doesn't look much like the initial patch, the latest version of these changes likely wouldn't have happened without those contributions.

----------
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11505>
_______________________________________

From report at bugs.python.org  Tue May 31 11:55:19 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 May 2011 09:55:19 +0000
Subject: [issue11505] string.py increased test coverage
In-Reply-To: <1300131460.79.0.278218518064.issue11505@psf.upfronthosting.co.za>
Message-ID: <1306835719.44.0.864539016687.issue11505@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11505>
_______________________________________

From report at bugs.python.org  Tue May 31 12:21:51 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 31 May 2011 10:21:51 +0000
Subject: [issue12222] All pysetup commands should respect exit codes
In-Reply-To: <1306833373.02.0.231767797102.issue12222@psf.upfronthosting.co.za>
Message-ID: <1306837311.1.0.06246066401.issue12222@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

fixed install in http://hg.python.org/cpython/rev/ebff46b232ed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12222>
_______________________________________

From report at bugs.python.org  Tue May 31 13:01:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 31 May 2011 11:01:37 +0000
Subject: [issue12164] str.translate docstring doesn't mention that 'table' can
	be None
In-Reply-To: <1306214084.99.0.386690557918.issue12164@psf.upfronthosting.co.za>
Message-ID: <1306839697.01.0.0286192053896.issue12164@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

After discussing with Ezio Melotti, I attached another patch with a different wording.

Mark: As a native English speaker, which one you prefer?

----------
Added file: http://bugs.python.org/file22206/str_translate_docstring_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12164>
_______________________________________

From report at bugs.python.org  Tue May 31 13:23:34 2011
From: report at bugs.python.org (Zhiping Deng)
Date: Tue, 31 May 2011 11:23:34 +0000
Subject: [issue12224] problem with siginterrupt
In-Reply-To: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>
Message-ID: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>


New submission from Zhiping Deng <kofreestyler at gmail.com>:

If socket timeout > 0, then there is no way to automatically
restart some socket calls like recv(). 
Calling siginterrupt(False) is useless, because python calls
internal_select() if socket has timeout, and select returns
error(EINTR) once interrupted by a signal, regardless of the
SA_RESTART flags.

So a user may have to wrap every socket calls in this case.

I found some related discussions in http://bugs.python.org/issue7978

----------
components: Library (Lib)
files: siginterrupt_example.py
messages: 137357
nosy: Zhiping.Deng
priority: normal
severity: normal
status: open
title: problem with siginterrupt
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22207/siginterrupt_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12224>
_______________________________________

From report at bugs.python.org  Tue May 31 13:52:24 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 31 May 2011 11:52:24 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306842744.62.0.663789574306.issue12082@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I tried to compile Python 3.3 (from default branch) with DONT_HAVE_FSTAT and DONT_HAVE_STAT. It seems to depend even more heavily on stat() being available, in other files than Python/import.c.

With 2.7, it was quite easy to disable the .pyc/.pyo writing in the absence of fstat(), but the NullImporter needs to be able to check for a directory. In addition, the build process fails when trying to run "setup.py build", because distutils cannot be imported. And it cannot be imported because it's a package, and packages (directories) cannot be detected without having stat().

So... Unless we have another way to check for a directory, I'm not sure whether it will be possible to compile Python at all without stat().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Tue May 31 15:25:46 2011
From: report at bugs.python.org (Tobias Brink)
Date: Tue, 31 May 2011 13:25:46 +0000
Subject: [issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than
	multiprocessing.Pool.map() for fast function argument
In-Reply-To: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>
Message-ID: <1306848346.89.0.901036941871.issue11271@psf.upfronthosting.co.za>


Tobias Brink <tobias.brink at gmail.com> added the comment:

I can confirm an overhead of 2 ms to 3 ms using a relatively recent Intel Core i5 CPU.

I (personally) believe these 3 ms to be a pretty big overhead on modern computers and I also believe that it would be relatively simple to reduce it.

I don't have much time at the moment but I will try to produce a complete proof of concept patch for the futures module in the next weeks. I'd be happy to get some comments when it is finished.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11271>
_______________________________________

From report at bugs.python.org  Tue May 31 16:42:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 14:42:56 +0000
Subject: [issue12224] problem with siginterrupt
In-Reply-To: <1306841014.72.0.255052920445.issue12224@psf.upfronthosting.co.za>
Message-ID: <1306852976.23.0.348028577732.issue12224@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Extract of manpage signal(7):

"The  following  interfaces  are never restarted after being interrupted by a signal handler, regardless of the use of SA_RESTART; they always fail with the error EINTR when interrupted by a signal handler:
 * ...
 * File descriptor multiplexing interfaces: epoll_wait(2), epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2)."

Consider siginterrupt(signal, False) as a "best-effort" trick... which doesn't work with select().

If you don't want select() to be interrupted by SIGINT, use:

pthread_sigmask(SIG_BLOCK, [SIGINT]);
select(...)
pthread_sigmask(SIG_UNBLOCK, [SIGINT])

or

pselect(...., [SIGINT])

pselect() is atomic, whereas pthread_sigmask+select is not.

I added recently pthread_sigmask() to the signal module in Python 3.3.

pselect() is not exposed in Python currently. We may add it if it's needed.

--

If you really don't care of SIGINT, you can also ignore it completly using signal(SIGINT, SIG_IGN).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12224>
_______________________________________

From report at bugs.python.org  Tue May 31 16:55:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 14:55:26 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1306853726.67.0.430051547505.issue7978@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using signalfd() (require Linux 2.6.22+), specified signals are written in a file and don't interrupt system calls (select). Bonus: we can wait for a signal using select!

Using pthread_sigmask(), you can also block signals before calling select, but it's not atomic. Or you can use pselect() which is pthread_sigmask()+select() in an atomic fashion.

pthread_sigmask() is already in Python 3.3, I plan to add signalfd() in a few weeks into Python 3.3. For pselect(), I don't know if we need it.

pthread_sigmask() is available on most POSIX systems, not on Windows. Can select() be interrupted by CTRL+c on Windows?

I don't say that we should not restart manually select() on EINTR, just that better solutions do exist today.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Tue May 31 16:55:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 14:55:57 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1306853757.48.0.529042702766.issue7978@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that #12224 is a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Tue May 31 16:57:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 14:57:24 +0000
Subject: [issue12221] segfaults with unexpanded $Revision$ id's in release
	candidate tarballs
In-Reply-To: <1306831663.83.0.751518346555.issue12221@psf.upfronthosting.co.za>
Message-ID: <1306853844.64.0.404309441639.issue12221@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/issue12221>
_______________________________________

From report at bugs.python.org  Tue May 31 17:16:17 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 31 May 2011 15:16:17 +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: <1306854977.0.0.17464717036.issue12225@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

configure works, but make immediately fails:

% make      
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
Traceback (most recent call last):
  File "./Parser/asdl_c.py", line 1214, in <module>
    main(args[0])
  File "./Parser/asdl_c.py", line 1158, in main
    mod.version = get_file_revision(srcfile)
  File "./Parser/asdl_c.py", line 1142, in get_file_revision
    p = subprocess.Popen(args, stdout=subprocess.PIPE)
  File "/usr/lib/python2.7/subprocess.py", line 672, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1202, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
make: *** [Include/Python-ast.h] Error 1

----------
messages: 137363
nosy: schmir
priority: normal
severity: normal
status: open
title: current tip doesn't build without mercurial installed
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________

From report at bugs.python.org  Tue May 31 17:23:12 2011
From: report at bugs.python.org (Josh Triplett)
Date: Tue, 31 May 2011 15:23:12 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306855392.13.0.390766969915.issue12082@psf.upfronthosting.co.za>


Josh Triplett <josh at joshtriplett.org> added the comment:

Rather than checking for a directory, how about just opening foo/__init__.py, and if that fails opening foo.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Tue May 31 17:30:15 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 31 May 2011 15:30:15 +0000
Subject: [issue12082] Python/import.c still references fstat even with
	DONT_HAVE_FSTAT/!HAVE_FSTAT
In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za>
Message-ID: <1306855815.92.0.943081843465.issue12082@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The NullImporter is documented to raise ImportError on directories, not directories containing __init__.py:

    http://docs.python.org/library/imp.html#imp.NullImporter

Checking for __init__.py{,c,o} seems doable to me without having stat().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12082>
_______________________________________

From report at bugs.python.org  Tue May 31 18:00:03 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 31 May 2011 16:00:03 +0000
Subject: [issue12170] Bytes.index() and bytes.count() should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1306857603.81.0.492914948222.issue12170@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/issue12170>
_______________________________________

From report at bugs.python.org  Tue May 31 18:19:02 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 May 2011 16:19:02 +0000
Subject: [issue12223] Datamodel documentation page: 'operator' where 'operand'
	should be
In-Reply-To: <1306834975.07.0.689179229064.issue12223@psf.upfronthosting.co.za>
Message-ID: <1306858742.01.0.943927163637.issue12223@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/issue12223>
_______________________________________

From report at bugs.python.org  Tue May 31 18:51:05 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 31 May 2011 16:51:05 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Before the next version is released, I'd like to push this one line modification to reduce the risk of sniffing Python development password when people upload packages to PyPI by using https:// communication channel by default.

Distutils doesn't validate PyPI server certificate, so this change doesn't prevent from MITM attacks, but at least it makes package submissions over wireless channels and public networks safer.

Taking into account that people still release packages for Python 2.5+ (AppEngine), I'd like to see this fix backported to at least Python 2.6

----------
assignee: tarek
components: Distutils, Distutils2
files: pypy.https.patch
keywords: patch
messages: 137366
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: use secured channel for uploading packages to pypi
type: security
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file22208/pypy.https.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 18:51:46 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 31 May 2011 16:51:46 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306860706.2.0.414311542137.issue12226@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This should probably be discussed on catalog-SIG, not the CPython bug tracker.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 18:51:54 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 31 May 2011 16:51:54 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306860714.09.0.68656180767.issue12226@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/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 18:52:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 31 May 2011 16:52:44 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306860764.48.0.52331684621.issue12226@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Oops, nevermind that, thought this was suggesting a change to PyPI itself, not distutils.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 18:54:08 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 31 May 2011 16:54:08 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306860848.62.0.192998906839.issue12226@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The distutils version that exposes this vulnerability is shipped with Python, that's why it is here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 18:54:23 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 31 May 2011 16:54:23 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306860863.43.0.801872671395.issue12226@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/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 19:04:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 31 May 2011 17:04:28 +0000
Subject: [issue12021] mmap.read requires an argument
In-Reply-To: <1306831597.46.0.438111858591.issue12021@psf.upfronthosting.co.za>
Message-ID: <BANLkTinjY4OQ6x4pP7AQMOO8rRcwPhit8g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I noticed that RawIOBase.read, TextIOBase.read, etc also accept None as the
> argument, treating it as -1. Should this be implemented, too?
>

That's because of the _PyIO_ConvertSsize_t converter, which silently
converts None to -1.
There's probably a good reason for doing this in the _io module, but I
don't see any reason to do the same thing in the mmap module (apart
from being consistent, of course).
Antoine?

If the patch is fine as-is, I'd like to commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12021>
_______________________________________

From report at bugs.python.org  Tue May 31 19:07:52 2011
From: report at bugs.python.org (poq)
Date: Tue, 31 May 2011 17:07:52 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1306861672.05.0.573191883726.issue12142@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

Tests succeed with this change.

There is only one use of _array_type, which is in the same module. This use is presumably tested, because the test fails if I change the line to _array_type = type(Structure).

In fact, everything must behave exactly the same after this change, because the two values are identical:

>>> from ctypes import *
>>> type(c_int * 3) is type(Array)
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12142>
_______________________________________

From report at bugs.python.org  Tue May 31 19:28:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 31 May 2011 17:28:13 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <201105302140.00131.victor.stinner@haypocalc.com>
Message-ID: <BANLkTikuBuMUYQgJCz=fset5ScsyVJr-AA@mail.gmail.com>


Charles-Fran??ois Natali <neologix at free.fr> added the comment:

> I like your patch, it removes many duplicate code :-)
>
> Some comments:

Patch attached.

> Doc/whatsnew/3.3.rst

Patch attached.

----------
Added file: http://bugs.python.org/file22209/pipe2_whatsnew.diff
Added file: http://bugs.python.org/file22210/support_linux_version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________
-------------- next part --------------
diff -r 6fb2e5fb9082 Doc/whatsnew/3.3.rst
--- a/Doc/whatsnew/3.3.rst	Tue May 31 12:15:42 2011 +0200
+++ b/Doc/whatsnew/3.3.rst	Tue May 31 19:27:08 2011 +0200
@@ -106,6 +106,11 @@
 os
 --
 
+* The :mod:`os` module has a new :func:`~os.pipe2` function that makes it
+  possible to create a pipe with :data:`~os.O_CLOEXEC` or :data:`os.O_NONBLOCK`
+  flags set atomically. This is especially useful to avoid race conditions in
+  multi-threaded programs.
+
 * The :mod:`os` module has a new :func:`~os.sendfile` function which provides
   an efficent "zero-copy" way for copying data from one file (or socket)
   descriptor to another. The phrase "zero-copy" refers to the fact that all of
-------------- next part --------------
diff -r 6fb2e5fb9082 Lib/test/support.py
--- a/Lib/test/support.py	Tue May 31 12:15:42 2011 +0200
+++ b/Lib/test/support.py	Tue May 31 19:20:57 2011 +0200
@@ -291,13 +291,24 @@
             msg = "Use of the `%s' resource not enabled" % resource
         raise ResourceDenied(msg)
 
-def linux_version():
+def requires_linux_version(*min_version):
+    """Raise SkipTest if the OS is Linux and the kernel version if less than
+    min_version.
+
+    For example, support.requires_linux_version(2, 6, 28) raises SkipTest if the
+    version is less than 2.6.28.
+    """
+    if not sys.platform.startswith('linux'):
+        return
     try:
         # platform.release() is something like '2.6.33.7-desktop-2mnb'
-        version_string = platform.release().split('-')[0]
-        return tuple(map(int, version_string.split('.')))
+        version_string = platform.release().split('-', 1)[0]
+        version = tuple(map(int, version_string.split('.')))
     except ValueError:
-        return 0, 0, 0
+        return
+    if version < min_version:
+        raise unittest.SkipTest("Linux kernel %s or higher required" %
+                                ".".join(map(str, min_version)))
 
 HOST = 'localhost'
 
diff -r 6fb2e5fb9082 Lib/test/test_posix.py
--- a/Lib/test/test_posix.py	Tue May 31 12:15:42 2011 +0200
+++ b/Lib/test/test_posix.py	Tue May 31 19:20:57 2011 +0200
@@ -310,10 +310,7 @@
 
     @unittest.skipUnless(hasattr(os, 'O_CLOEXEC'), "needs os.O_CLOEXEC")
     def test_oscloexec(self):
-        version = support.linux_version()
-        if sys.platform == 'linux2' and version < (2, 6, 23):
-            self.skipTest("Linux kernel 2.6.23 or higher required, "
-                          "not %s.%s.%s" % version)
+        support.requires_linux_version(2, 6, 23)
         fd = os.open(support.TESTFN, os.O_RDONLY|os.O_CLOEXEC)
         self.addCleanup(os.close, fd)
         self.assertTrue(fcntl.fcntl(fd, fcntl.F_GETFD) & fcntl.FD_CLOEXEC)
@@ -480,10 +477,7 @@
 
     @unittest.skipUnless(hasattr(os, 'pipe2'), "test needs os.pipe2()")
     def test_pipe2(self):
-        version = support.linux_version()
-        if sys.platform == 'linux2' and version < (2, 6, 27):
-            self.skipTest("Linux kernel 2.6.27 or higher required, "
-                          "not %s.%s.%s" % version)
+        support.requires_linux_version(2, 6, 27)
         self.assertRaises(TypeError, os.pipe2, 'DEADBEEF')
         self.assertRaises(TypeError, os.pipe2, 0, 0)
 
diff -r 6fb2e5fb9082 Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Tue May 31 12:15:42 2011 +0200
+++ b/Lib/test/test_socket.py	Tue May 31 19:20:57 2011 +0200
@@ -1024,10 +1024,7 @@
 
     if hasattr(socket, "SOCK_NONBLOCK"):
         def testInitNonBlocking(self):
-            v = support.linux_version()
-            if v < (2, 6, 28):
-                self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                              % ".".join(map(str, v)))
+            support.requires_linux_version(2, 6, 28)
             # reinit server socket
             self.serv.close()
             self.serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM |
@@ -2002,10 +1999,7 @@
 @unittest.skipUnless(fcntl, "module fcntl not available")
 class CloexecConstantTest(unittest.TestCase):
     def test_SOCK_CLOEXEC(self):
-        v = support.linux_version()
-        if v < (2, 6, 28):
-            self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                          % ".".join(map(str, v)))
+        support.requires_linux_version(2, 6, 28)
         with socket.socket(socket.AF_INET,
                            socket.SOCK_STREAM | socket.SOCK_CLOEXEC) as s:
             self.assertTrue(s.type & socket.SOCK_CLOEXEC)
@@ -2024,10 +2018,7 @@
             self.assertEqual(s.gettimeout(), None)
 
     def test_SOCK_NONBLOCK(self):
-        v = support.linux_version()
-        if v < (2, 6, 28):
-            self.skipTest("Linux kernel 2.6.28 or higher required, not %s"
-                          % ".".join(map(str, v)))
+        support.requires_linux_version(2, 6, 28)
         # a lot of it seems silly and redundant, but I wanted to test that
         # changing back and forth worked ok
         with socket.socket(socket.AF_INET,

From report at bugs.python.org  Tue May 31 19:30:31 2011
From: report at bugs.python.org (Graham Cummins)
Date: Tue, 31 May 2011 17:30:31 +0000
Subject: [issue12227] multiprocessing.Pool initialization seems to call
	methods it should not (and on badly formed objects)
In-Reply-To: <1306863031.61.0.944482531779.issue12227@psf.upfronthosting.co.za>
Message-ID: <1306863031.61.0.944482531779.issue12227@psf.upfronthosting.co.za>


New submission from Graham Cummins <grahamiancummins at gmail.com>:

When attempting to pass instances of a custom class in the argument list
of a multiprocessing.Pool.map call, I encounter an inexplicable AttributeError. A simplified test script that creates the bug is included. It fails for both Python 2.7.1 and 3.2 on my 4-core 64 bit linux machine.

Briefly, the code creates a subclass of "dict" that checks for a "_ro" attribute before handling a "__setitem__". Empty instances of this class
can be passed to Pool.map fine, but if they have any content, I get
that multiprocessing/queues.py, line 378 ("recv()"), calls my custom __setitem__, which fails, due to a missing _ro attribute. 

This is very confusing. For one thing, much of the Traceback seems
missing. recv() is not directly a call to my customized __setitem__, 
and I can't thing why it should ever need to invoke such a call  

For another, the custom class _does_ set the _ro attribute, on __init__. Testing for this attribute, or calling __setitem__, succeeds in every other context I've tested, so it seems that the instance that is 
being used in the multiprocessing context is not the same underlying object that I pass in.

----------
components: Library (Lib)
files: bug.py
messages: 137373
nosy: Graham.Cummins
priority: normal
severity: normal
status: open
title: multiprocessing.Pool initialization seems to call methods it should not (and on badly formed objects)
versions: Python 2.7
Added file: http://bugs.python.org/file22211/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12227>
_______________________________________

From report at bugs.python.org  Tue May 31 19:42:50 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 31 May 2011 17:42:50 +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: <1306863770.76.0.976811825143.issue12225@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

FYI, the dependency is introduced in changeset http://hg.python.org/cpython/rev/0daa6ba25d9b

----------
components: +Build
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________

From report at bugs.python.org  Tue May 31 19:53:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2011 17:53:32 +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: <1306864412.31.0.910495130961.issue12225@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm closing this as invalid/duplicate, but I'm sure this isn't the last time we'll get this report.  It would be nice if we could think of a way to improve the situation.

----------
nosy: +benjamin.peterson, r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Parser/asdl_c.py relies on mercurial repository revision

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________

From report at bugs.python.org  Tue May 31 19:58:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 31 May 2011 17:58:00 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1306811332.95.0.283776934259.issue6560@psf.upfronthosting.co.za>
Message-ID: <BANLkTimFzrUXGCU=wMCTUA0ad69w84Tv8g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> What needs to happen to get recvmsg() supported in Python?

Well, I guess that the only reason is that no committer is motivated
enough to bring this into Python: it's a rather large patch, and
honestly, I'm not sure that many people are going to use it.
The feature I personally like the most about sendmsg/recvmsg is the
ability to do scatter-gather I/O, but if the performance is critical,
then I won't be using Python.
I know that sendmsg also has some other advantages (passing FDs,
ancillary data...).

> recvmsg() is required to get get transparent UDP proxies working under Linux
> using tproxy, the code needs to run recvmsg() to be able to find out what the
> original destination address was for the the packet.

Sounds like a job for raw sockets, no? (well, you need CAP_NET_RAW)

In short, I think that you just need to find a core developer
interested, I personally am not (but I'm not opposed to it either :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue May 31 20:01:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 31 May 2011 18:01:42 +0000
Subject: [issue12228] Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK
	description
In-Reply-To: <1306864902.26.0.858229152162.issue12228@psf.upfronthosting.co.za>
Message-ID: <1306864902.26.0.858229152162.issue12228@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following http://mail.python.org/pipermail/docs/2011-May/004429.html, here's a patch that fix the swap of those 2 flags description; it applies cleanly (except for some offset) on 2.7, 3.1, 3.2 and default.

----------
assignee: docs at python
components: Documentation
files: doc_stat_uf_opaque_nounlink-py27.patch
keywords: patch
messages: 137377
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Stat doc - fix swap of UF_OPAQUE and UF_NOUNLINK description
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22212/doc_stat_uf_opaque_nounlink-py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12228>
_______________________________________

From report at bugs.python.org  Tue May 31 20:16:30 2011
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 31 May 2011 18:16:30 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1306865790.72.0.188424933706.issue9969@psf.upfronthosting.co.za>


Changes by Thomas Kluyver <takowl at gmail.com>:


----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Tue May 31 20:21:09 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 31 May 2011 18:21:09 +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: <1306866069.48.0.0836466577847.issue12225@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

duplicate of http://bugs.python.org/issue12152

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________

From report at bugs.python.org  Tue May 31 20:24:25 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 31 May 2011 18:24:25 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306866265.08.0.378188441888.issue12226@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 20:25:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2011 18:25:22 +0000
Subject: [issue12142] Reference cycle when importing ctypes
In-Reply-To: <1306017588.73.0.650837416325.issue12142@psf.upfronthosting.co.za>
Message-ID: <1306866322.26.0.454959916741.issue12142@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for the test and explanation. There currently is no specific cytpes maintainer. But from what you have said, I might feel comfortable enough applying this, if no one else does, when I have the necessary setup on a new machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12142>
_______________________________________

From report at bugs.python.org  Tue May 31 20:26:39 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2011 18:26:39 +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: <1306866399.09.0.846482459402.issue12225@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I should have mentioned the bug number in the body, thanks for adding that.  FYI, the bug number also appears in the 'superseder' field, and (more interesting to you in this context) if you just say, for example, 
issue 12152 or #12152 roundup will automatically turn it into a link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________

From report at bugs.python.org  Tue May 31 20:38:00 2011
From: report at bugs.python.org (Herm Fischer)
Date: Tue, 31 May 2011 18:38:00 +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: <1306867080.17.0.102838715664.issue12219@psf.upfronthosting.co.za>


Herm Fischer <fischer at markv.com> added the comment:

I've now tried this issue on python.org's own 3.2 and 3.2.1rc1 (64 bit) builds, and they also do have the same problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12219>
_______________________________________

From report at bugs.python.org  Tue May 31 20:48:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 31 May 2011 18:48:55 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1306512320.89.0.122181363068.issue8407@psf.upfronthosting.co.za>
Message-ID: <BANLkTimpSSOFirqxqx17BcTtDW_VfBjeEw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The wakeup fd now contains the number of each signal, and so the behaviour has
> to change. I applied your patch and I added a test.

Interesting. I suspected this would have an impact on the test_signal
failure on the FreeBSD 6.4 buidbot:

"""
======================================================================
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).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Tue May 31 21:13:20 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 31 May 2011 19:13:20 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306869200.85.0.933067765276.issue12226@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Have you tried registering/uploading stuff through https ? if it's working as is I am +1 for this change in the next 2.7.x. 

For 2.6 don't know if it's worth a security patch. Martin, Barry, any opinion ?

----------
nosy: +barry, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 21:50:29 2011
From: report at bugs.python.org (Graham Cummins)
Date: Tue, 31 May 2011 19:50:29 +0000
Subject: [issue12227] multiprocessing.Pool initialization seems to call
	methods it should not (and on badly formed objects)
In-Reply-To: <1306863031.61.0.944482531779.issue12227@psf.upfronthosting.co.za>
Message-ID: <1306871429.54.0.287861561398.issue12227@psf.upfronthosting.co.za>


Graham Cummins <grahamiancummins at gmail.com> added the comment:

As far as I can tell, this is a version of the scope-dependent un-pickling issue mentioned in the documentation. I'm still rather confused, since in the original occurrence of the issue happens despite the fact that subprocesses should be able to import all relevant modules (unless they have a very odd environment), and the original class is pickleable. Still, until I can clearly distinguish my difficulty from the know issues presented in the programming guidelines, I see no reason to have it listed as a bug.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12227>
_______________________________________

From report at bugs.python.org  Tue May 31 22:15:28 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 31 May 2011 20:15:28 +0000
Subject: [issue12226] use secured channel for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1306872928.03.0.784501835339.issue12226@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Yes. I've just uploaded http://pypi.python.org/pypi/review/r749 through https://pypi.python.org/pypi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Tue May 31 22:27:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2011 20:27:05 +0000
Subject: [issue12196] add pipe2() to the os module
In-Reply-To: <BANLkTikuBuMUYQgJCz=fset5ScsyVJr-AA@mail.gmail.com>
Message-ID: <201105312226.59672.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

support_linux_version.diff: cool, it's even better than the previous patch. You 
can commit it, except if you are motived for a last change: display the write 
also version in the SkipTest message (as it is done actually).

pipe2_whatsnew.diff: I don't have any special to say, except that you didn't 
use ~ for :data:`os.O_NONBLOCK`. Go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12196>
_______________________________________

From report at bugs.python.org  Tue May 31 22:31:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 May 2011 20:31:47 +0000
Subject: [issue8407] expose signalfd(2) and pthread_sigmask in the signal
	module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <E1QRVbO-0005A1-AC@dinsdale.python.org>


Roundup Robot <devnull at devnull> added the comment:

New changeset 29e08a98281d by Victor Stinner in branch 'default':
Issue #8407: test_signal doesn't check signal delivery order
http://hg.python.org/cpython/rev/29e08a98281d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Tue May 31 23:02:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 31 May 2011 21:02:57 +0000
Subject: [issue10772] Several actions for argparse arguments missing from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1306875777.97.0.805944352137.issue10772@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/issue10772>
_______________________________________

From report at bugs.python.org  Tue May 31 23:13:53 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 31 May 2011 21:13:53 +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: <1306876433.66.0.89700595197.issue12225@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

here's a patch that fixes the issue.
You can use hg import to apply it to your hg repo, autoconf has to be run afterwards.

The log message is:

    disable ASDLGEN if hg won't work, or if python is not installed.
    
    This change makes configure check for
    - the existence of a hg repository
    - the hg executable itself
    - the python executable
    
    Running $(srcdir)/Parser/asdl_c.py (i.e. ASDLGEN) will fail if any of
    the above prerequisites is missing, so we now disable it instead.
    
    Also see http://bugs.python.org/issue12225 and
    http://bugs.python.org/issue12152

----------
keywords: +patch
Added file: http://bugs.python.org/file22213/0001-disable-ASDLGEN-if-hg-won-t-work-or-if-python-is-not.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________

From report at bugs.python.org  Tue May 31 23:17:53 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 31 May 2011 21:17:53 +0000
Subject: [issue12152] Parser/asdl_c.py relies on mercurial repository revision
In-Reply-To: <1306136998.74.0.24135440074.issue12152@psf.upfronthosting.co.za>
Message-ID: <1306876673.75.0.0363977803404.issue12152@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

issue 12225 contains a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12152>
_______________________________________

From report at bugs.python.org  Tue May 31 23:29:28 2011
From: report at bugs.python.org (John O'Connor)
Date: Tue, 31 May 2011 21:29:28 +0000
Subject: [issue12229] Remove unused variable in bufferedio.c
In-Reply-To: <1306877368.88.0.968451674352.issue12229@psf.upfronthosting.co.za>
Message-ID: <1306877368.88.0.968451674352.issue12229@psf.upfronthosting.co.za>


New submission from John O'Connor <tehjcon at gmail.com>:

Remove second (unused) argument to _bufferedreader_peek_unlocked()

----------
components: IO
files: bufferedreader_peek.patch
keywords: patch
messages: 137391
nosy: haypo, jcon, pitrou
priority: normal
severity: normal
status: open
title: Remove unused variable in bufferedio.c
versions: Python 3.3
Added file: http://bugs.python.org/file22214/bufferedreader_peek.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12229>
_______________________________________

From report at bugs.python.org  Tue May 31 23:32:47 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 31 May 2011 21:32:47 +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: <1306877567.53.0.235496672364.issue12225@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I've setup a hg repo on bitbucket with that patch.

----------
hgrepos: +24

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________

From report at bugs.python.org  Tue May 31 23:34:36 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 31 May 2011 21:34:36 +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: <1306877676.71.0.167812747815.issue12225@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


Added file: http://bugs.python.org/file22215/0908fbf86e43.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12225>
_______________________________________