[issue6800] os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application

Reid Kleckner added the comment: Supposedly this bug also affects FreeBSD, but I can't verify it. I'd say the problem isn't going away, at least not for that platform, but I don't feel like it's worth bending over backwards to deal with it either. As far as it concerns unladen swallow, we'll b

[issue6800] os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application

Ronald Oussoren added the comment: The issue with execv seems to be resolved on OSX 10.6, and hence the problem will go away by itself in the future. But until OSX 10.5 and earlier have died of this is a valid issue. My gut feeling is that I'm -1 on killing all threads in os.execv because it

[issue6247] should we include argparse

R. David Murray added the comment: I'm +1 on inclusion one way or another as well. I haven't made time to do anything other than a cursory code review, but as an end user I find the module fits my needs much better than optparse. -- nosy: +r.david.murray __

[issue2204] document ConfigParser behaviour when a file has same section multiple times

trash80 added the comment: I am using configparser after combining 3 or so ini files, I would like to merge similar sections rather than throwing an exception. Right now I have to make sure the ini files all have unique sections, but I would like to able to use same section names, then combine

[issue6800] os.exec* raises "OSError: [Errno 45] Operation not supported" in a multithreaded application

New submission from Reid Kleckner : The test case is attached. On Mac OS X (and presumably FreeBSD, which has the same behavior) when you try to exec from a process that has any other threads in it, you get an OSError, "Operation not supported". Here's the output on my MacBook: Traceback (most

[issue6247] should we include argparse

Gregory P. Smith added the comment: we should never pretend an old module doesn't exist. leave optparse as optparse. argparse can come in under its own name. we can mark getopt and optparse as deprecated at some point and remove them in 10 years :) +1 on inclusion btw. It looks like it'll o

[issue6247] should we include argparse

Mark Lodato added the comment: I would also like to voice support for including argparse in the standard library. It seems silly to deny a module from being added just because we already have two inferior ones. Argparse adds so many new (and badly needed!) features that it would be very diffic

[issue6799] mimetypes does not give cannonical extension for guess_extension with text/plain

New submission from Paul Tarjan : >>> import mimetypes >>> mimetypes.guess_extension("text/plain") '.ksh' most others are correct, it is just this one is quite wrong. I would recommend changing it to .txt . >>> mimetypes.guess_all_extensions("text/plain") ['.ksh', '.pl', '.c', '.bat', '.h', '

[issue6798] Argument for sys.settrace() callbacks documented incorrectly

New submission from Robert Kern : The final 'arg' argument of the sys.settrace() callback is documented to be None for the 'c_return' and 'c_exception' events, but it appears to be the function object itself. Additionally, the 'return' event's argument may be None if the 'return' event is being g

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Sridhar Ratnakumar added the comment: libc used is of version 2.3.2. *** a...@gila:~> ldd rrun/tmp/autotest/ActivePython-3.1.1.2-linux-x86/ INSTALLDIR/bin/python3 libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4002f000) libdl.so.2 => /lib/libdl.so.2 (0x4008) libuti

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Sridhar Ratnakumar added the comment: .. and here are the machine details: a...@gila:~> uname -a Linux gila 2.4.21-297-default #1 Sat Jul 23 07:47:39 UTC 2005 i686 i686 i386 GNU/Linux a...@gila:~> cat /etc/*release LSB_VERSION="1.3" DISTRIB_ID="SuSE" DISTRIB_RELEASE="9.0" DISTRIB_DESCRIPTION="

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32

Sridhar Ratnakumar added the comment: Sorry about the late response; have been busy of late. I believe this error ("Unknown signal 32") appears consistently in 3.0.1, 3.1rc1, 3.1 and 3.1.1. It appears only on Linux x86. (64-bit has failures of different kind..) I am attaching the entire log

[issue6797] When Beginning Expression with Lookahead Assertion I get no Matches

New submission from Jonathan Windle : Example Code: import re re.findall(r"(?![a-z0-9])0(?![a-z0-9])", "a0a 0 0 b0b") The above code returns an empty list. I expect to get ['0', '0'] returned. If I remove "(?![a-z0-9])" from the beginning of the expression string findall returns values as expe

[issue6792] Distutils-based installer does not detect 64bit versions of Python

Martin v. Löwis added the comment: Unfortunately, I don't think this is possible. When creating the installer, you have to make a choice whether to make it a 32-bit or a 64-bit MSI file - whether or not you have any architecture dependency. At least, can't think of an easy way to solve it. ---

[issue6054] tarfile normalizes arcname

Lars Gustäbel added the comment: I have done some research in order to find a suitable behaviour for tarfile. I wrote a script to test to what extent all the different tar implementations transform input pathnames. The results can be found at http://www.gustaebel.de/lars/tarfile/wwgtd.html. My

[issue6786] readline and zero based indexing

Terry J. Reedy added the comment: Please ask questions on, for instance, the python-list (c.l.p). If you find evidence that this is actually a bug, please supply. Else, close (or change to doc issue -- see below). My *guess* is that history lists are 1-based and Python conforms to that. If so,

[issue6771] Curses.wrapper: documentation/implementation error

Changes by Terry J. Reedy : -- title: documentation/implementation error -> Curses.wrapper: documentation/implementation error ___ Python tracker ___

[issue6765] math.log, log10 inconsistency

Terry J. Reedy added the comment: Reopening as doc issue. This is at least the second time this issue has been reported (see #3724), with some agreement on doc tweak, but not done. Specific suggestions for math module doc, 9.2.2: math.log(x[, base]) Return the logarithm of x to the given base

[issue6498] Py_Main() does not return on SystemExit

Rogi added the comment: I will try to fix and submit a patch. Just a second =op -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue6796] invalid print in tkinter\test\test_ttk\test_widgets.py

New submission from Keith Campbell : Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> RESTART >>> >>>

[issue6795] decimal.py: minor issues && usability

Mark Dickinson added the comment: Thanks for the reports. Issue 1. If this is going to be changed, I'd rather see int(Decimal('nan')) raise ValueError (just as int(float('nan')) does) than return None. Conversions from Decimal to native integers lie outside the scope of the standard, so the

[issue6793] decimal.py: div_nearest ==> _div_nearest

Mark Dickinson added the comment: There's a security-fixes only policy in place for the 2.5 branch, so I'm afraid this isn't going to happen. -- ___ Python tracker ___ _

[issue6793] decimal.py: div_nearest ==> _div_nearest

Stefan Krah added the comment: Yes, it is also fixed in 2.6 maintenance. I was hoping it could go into 2.5 maintenance. -- ___ Python tracker ___

[issue6794] decimal.py: incorrect results in NaN comparisons

Mark Dickinson added the comment: Thanks for the report! I've applied a quick fix in the trunk in r74564; merged to other branches in r74565 (release26-maint), r74566 (py3k) and r74567 (release31-maint). -- resolution: -> fixed stage: -> committed/rejected status: open -> closed _

[issue6793] decimal.py: div_nearest ==> _div_nearest

Changes by R. David Murray : -- keywords: +26backport resolution: fixed -> out of date ___ Python tracker ___ ___ Python-bugs-list mail

[issue6795] decimal.py: minor issues && usability

Changes by Mark Dickinson : -- assignee: -> marketdickinson nosy: +marketdickinson ___ Python tracker ___ ___ Python-bugs-list mailing

[issue6275] let unittest.assertRaises() return the exception object caught

Michael Foord added the comment: Cool. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue6794] decimal.py: incorrect results in NaN comparisons

Changes by Mark Dickinson : -- assignee: -> marketdickinson versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker ___ _

[issue6795] decimal.py: minor issues && usability

New submission from Stefan Krah : Hi, a couple of minor issues: 1: >>> c = getcontext() >>> c.traps[InvalidOperation] = False >>> Decimal("NaN").__int__() Decimal('NaN') I think the return value should be None. 2: >>> c = getcontext() >>> c.traps[InvalidOperation] = False >>> Decimal("NaN").

[issue6793] decimal.py: div_nearest ==> _div_nearest

Ezio Melotti added the comment: This is already fixed in the trunk. -- nosy: +ezio.melotti, marketdickinson resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker

[issue6794] decimal.py: incorrect results in NaN comparisons

Changes by Ezio Melotti : -- nosy: +marketdickinson priority: -> normal type: -> behavior ___ Python tracker ___ ___ Python-bugs-list

[issue6794] decimal.py: incorrect results in NaN comparisons

New submission from Stefan Krah : Hi, I believe the following comparisons aren't correct: 1: Decimal("-sNaN63450748854172416").compare_total(Decimal("-sNaN911993")) ==> Decimal('1') Should be: Decimal('-1') (checked against decNumber) 2: Decimal("NaN1").compare_total_mag(Decimal

[issue6793] decimal.py: div_nearest ==> _div_nearest

New submission from Stefan Krah : --- a-decimal.py2009-08-28 11:48:45.0 +0200 +++ b-decimal.py2009-08-28 11:49:47.0 +0200 @@ -4845,7 +4845,7 @@ log_tenpower = f*M # exact else: log_d = 0 # error < 2.31 -log_tenpower = div_nearest(f,

[issue6791] httplib read status memory usage

sumar added the comment: I've also check patch against code in svn tree: wget http://svn.python.org/projects/python/trunk/Lib/httplib.py patch -p0 -i httplib.patch --dry-run patching file httplib.py Hunk #1 succeeded at 209 (offset 54 lines). Hunk #2 succeeded at 303 (offset 10 lines).

[issue6784] byte/unicode pickle incompatibilities between python2 and python3

Changes by RonnyPfannschmidt : -- title: byte/unicode pickle incompatibilities between python2 andand python3 -> byte/unicode pickle incompatibilities between python2 and python3 ___ Python tracker

[issue5468] urlencode does not handle "bytes", and could easily handle alternate encodings

Miles Kaufmann added the comment: I've attached a patch that provides similar functionality to Dan Mahn's urlencode(), as well as providing encoding and errors parameters to parse_qs and parse_qsl, updating the documentation to reflect the added parameters, and adding test cases. The impleme

[issue6792] Distutils-based installer does not detect 64bit versions of Python

New submission from erluk : An installer for source-only modules created using distutils (bdist_wininst) will only detect 32bit installations of Python on 64bit Windows machines. Expected behaviour: The installer lists 32bit and 64bit installations of Python on the machine. -- assignee:

[issue6791] httplib read status memory usage

New submission from sumar : During writing some code I discovered some behaviour of httplib. When we connect to host, which doesn’t respond with status line, but it just sending data, httplib may consume more and more memory, becouce when we execute h = httplib.HTTPConnection(‘host’) h.conect() h