[issue6791] httplib read status memory usage
New submission from sumar m.sucaj...@gmail.com: 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.request(‘GET’, ‘/’) r = h.getresponse() httplib tries to read one line from host. If host doesn’t send new line character (‘\n’), httplib reads more and more data. On my tests httplib could consume all of 4GB of memory and the python process was killed by oom_killer. The resolution is to limit maximum amount of data read on getting response. I have performed some test: I received 3438293 from hosts located in the network. The longest valid response line is HTTP/1.1 500 ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )\r\n and it has 197 characters. In RFC2616 in section 6.1 we have: “The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF (..)The Reason-Phrase is intended to give a short textual description of the Status-Code.” So limiting maximum status line length to 256 characters is a solution of this problem. It doesn’t break compatibility withc RFC 2616. My patch was written originally on python2.4, but I’ve tested it on python2.6: [...@host python2.6]$ patch --dry-run -i /home/ms/httplib.patch patching file httplib.py Hunk #1 succeeded at 209 (offset 54 lines). -- components: Library (Lib) files: httplib.patch keywords: patch messages: 92027 nosy: m.sucajtys severity: normal status: open title: httplib read status memory usage type: resource usage versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file14795/httplib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6791 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
New submission from erluk er...@pargalaxy.de: 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: tarek components: Distutils messages: 92028 nosy: erluk, tarek severity: normal status: open title: Distutils-based installer does not detect 64bit versions of Python type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6791] httplib read status memory usage
sumar m.sucaj...@gmail.com 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). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6791 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6793] decimal.py: div_nearest == _div_nearest
New submission from Stefan Krah stefan-use...@bytereef.org: --- 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, 10**-p) # error 0.5 +log_tenpower = _div_nearest(f, 10**-p) # error 0.5 return _div_nearest(log_tenpower+log_d, 100) -- components: Library (Lib) messages: 92031 nosy: skrah severity: normal status: open title: decimal.py: div_nearest == _div_nearest versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6793 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6784] byte/unicode pickle incompatibilities between python2 and python3
Changes by RonnyPfannschmidt ronny.pfannschm...@gmx.de: -- title: byte/unicode pickle incompatibilities between python2 andand python3 - byte/unicode pickle incompatibilities between python2 and python3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5468] urlencode does not handle bytes, and could easily handle alternate encodings
Miles Kaufmann mile...@umich.edu 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 implementation of urlencode() is not the same as dmahn's, and has a more straightforward control flow and less code duplication than the current implementation. (For the tests, I tried to match the style of the file I was adding to with regard to (expect, result) order, which is why it's inconsistent.) -- keywords: +patch versions: +Python 3.2 Added file: http://bugs.python.org/file14796/urllib_parse.py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6794] decimal.py: incorrect results in NaN comparisons
New submission from Stefan Krah stefan-use...@bytereef.org:
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(-NaN99))
== Decimal('-1')
Should be: Decimal('1') (checked against decNumber)
--
components: Library (Lib)
messages: 92032
nosy: skrah
severity: normal
status: open
title: decimal.py: incorrect results in NaN comparisons
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6794
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6794] decimal.py: incorrect results in NaN comparisons
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +marketdickinson priority: - normal type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6793] decimal.py: div_nearest == _div_nearest
Ezio Melotti ezio.melo...@gmail.com added the comment: This is already fixed in the trunk. -- nosy: +ezio.melotti, marketdickinson resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6793 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6795] decimal.py: minor issues usability
New submission from Stefan Krah stefan-use...@bytereef.org:
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).__long__()
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded in cmp
3:
setcontext(8)
getcontext()
8
This is just a usability issue, perhaps a type check could be performed.
--
components: Library (Lib)
messages: 92034
nosy: skrah
severity: normal
status: open
title: decimal.py: minor issues usability
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6795
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6794] decimal.py: incorrect results in NaN comparisons
Changes by Mark Dickinson dicki...@gmail.com: -- assignee: - marketdickinson versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6275] let unittest.assertRaises() return the exception object caught
Michael Foord mich...@voidspace.org.uk added the comment: Cool. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6795] decimal.py: minor issues usability
Changes by Mark Dickinson dicki...@gmail.com: -- assignee: - marketdickinson nosy: +marketdickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6793] decimal.py: div_nearest == _div_nearest
Changes by R. David Murray rdmur...@bitdance.com: -- keywords: +26backport resolution: fixed - out of date ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6793 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6794] decimal.py: incorrect results in NaN comparisons
Mark Dickinson dicki...@gmail.com 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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6793] decimal.py: div_nearest == _div_nearest
Stefan Krah stefan-use...@bytereef.org added the comment: Yes, it is also fixed in 2.6 maintenance. I was hoping it could go into 2.5 maintenance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6793 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6793] decimal.py: div_nearest == _div_nearest
Mark Dickinson dicki...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue6793 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6795] decimal.py: minor issues usability
Mark Dickinson dicki...@gmail.com 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 there's not much help there. However, precisely *because*
they lie outside the standard, it seems wrong to be raising a Decimal
exception (Decimal.InvalidContext) here. It's also inconsistent with
the treatment of infinities: int(Decimal('infinity')) currently gives
an OverflowError.
Given the lack of guidance from the decimal standard, the next place to
turn is probably IEEE 754. IEEE 754-2008, section 5.8 (Details of
conversions from floating-point to integer formats) says:
When a NaN or infinite operand cannot be represented in the
destination format and this cannot otherwise be indicated, the invalid
operation exception shall be signaled.
As far as I can tell, when the invalid-operation trap is disabled, the
return value is undefined in this case (see 7.2(i) in IEEE 754-2008).
But in Python this error condition *can* 'otherwise be indicated', by
raising a suitable Python exception. So I propose changing the decimal
module in 2.7 and 3.2 so that int(Decimal('nan')) and
long(Decimal('nan')) raise ValueError.
Raymond, Facundo: any thoughts on this?
Issue 2. A clear bug; will fix. Thanks.
Issue 3. I can't see how this could cause any real problems, since you'd
get an error as soon as you tried to use a bogus context. Further, an
explicit typecheck goes against Python's duck-typing philosophy: a
suitably crazy and misguided person ought to be able to create their own
'quacks like a context' class, not necessarily inheriting from
Decimal.Context, and pass this into setcontext in place of a real
context. I'm -0 on changing this.
--
nosy: +facundobatista, rhettinger
priority: - normal
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6795
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6796] invalid print in tkinter\test\test_ttk\test_widgets.py
New submission from Keith Campbell kei...@mitre.org: 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 RESTART Traceback (most recent call last): File C:\Python31\Lib\tkinter\test\test_ttk\test_widgets.py, line 4, in module from test.support import requires, run_unittest File c:\spring2000\o7python\lib\test.py, line 33 print 'Main process exiting.' ^ SyntaxError: invalid syntax -- components: Tkinter messages: 92040 nosy: keithc severity: normal status: open title: invalid print in tkinter\test\test_ttk\test_widgets.py type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6796 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6498] Py_Main() does not return on SystemExit
Rogi r...@linuxmail.org added the comment: I will try to fix and submit a patch. Just a second =op -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6498 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6765] math.log, log10 inconsistency
Terry J. Reedy tjre...@udel.edu 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. add: , calculated as log(x)/log(base) before period. [This could be removed if better method ever implemented.] math.log10(x) Return the base-10 logarithm of x. add: This is usually more accurate than log(x, 10). -- assignee: - georg.brandl components: +Documentation -Library (Lib) nosy: +georg.brandl, tjreedy resolution: invalid - status: closed - open versions: +Python 2.6, Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6771] Curses.wrapper: documentation/implementation error
Changes by Terry J. Reedy tjre...@udel.edu: -- title: documentation/implementation error - Curses.wrapper: documentation/implementation error ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6786] readline and zero based indexing
Terry J. Reedy tjre...@udel.edu 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, the doc should mention that. But I do not know. -- nosy: +tjreedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6054] tarfile normalizes arcname
Lars Gustäbel l...@gustaebel.de 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 conclusion is the following: tarfile now does no pathname transformation whatsoever except for converting absolute to relative paths (to stay backwards compatible). This way tarfile is closer to POSIX, applies less magic and gives more responsibility to the user. Fixed in r74571 (trunk) and r74573 (py3k). Thanks for your report. -- resolution: - fixed status: open - closed versions: +Python 3.2 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6054 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Martin v. Löwis mar...@v.loewis.de 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. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6797] When Beginning Expression with Lookahead Assertion I get no Matches
New submission from Jonathan Windle jonathanwin...@gmail.com: 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 expected. -- components: Regular Expressions messages: 92046 nosy: jwindle severity: normal status: open title: When Beginning Expression with Lookahead Assertion I get no Matches type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6797 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32
Sridhar Ratnakumar sridh...@activestate.com 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 file. I don't have much time to investigate into this relatively less- important issue in detail, but if you need any further information .. please let me know. I will be happy to provide. -- Added file: http://bugs.python.org/file14797/apy3.1.1-linux-x86-apytest.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32
Sridhar Ratnakumar sridh...@activestate.com 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=SuSE Linux 9.0 (i586) SuSE Linux 9.0 (i586) VERSION = 9.0 a...@gila:~ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32
Sridhar Ratnakumar sridh...@activestate.com 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) libutil.so.1 = /lib/libutil.so.1 (0x40083000) libm.so.6 = /lib/i686/libm.so.6 (0x40086000) libc.so.6 = /lib/i686/libc.so.6 (0x400aa000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) a...@gila:~ /lib/i686/libc.so.6 GNU C Library stable release version 2.3.2 (20030827), by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured for i686-suse-linux. Compiled by GNU CC version 3.3.1 (SuSE Linux). Compiled on a Linux 2.6.0-test3 system on 2003-09-23. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy NoVersion patch for broken glibc 2.0 binaries BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. pthread library is compiled with floating stack support enabled. Report bugs using the `glibcbug' script to b...@gnu.org. a...@gila:~ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6798] Argument for sys.settrace() callbacks documented incorrectly
New submission from Robert Kern robert.k...@gmail.com: 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 generated because of an exception. These errors also exist in the Py_tracefunc documentation in the C API. The latter error is not particularly important for the Python API, but in the C API the argument may be a NULL pointer. I am happy to make the corrections if someone will confirm that my analysis is correct. -- assignee: georg.brandl components: Documentation messages: 92050 nosy: georg.brandl, robert.kern severity: normal status: open title: Argument for sys.settrace() callbacks documented incorrectly type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6799] mimetypes does not give cannonical extension for guess_extension with text/plain
New submission from Paul Tarjan pyt...@paulisageek.com: 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', '.txt', '.asc', '.text', '.pot', '.brf'] -- components: Library (Lib) messages: 92051 nosy: ptarjan severity: normal status: open title: mimetypes does not give cannonical extension for guess_extension with text/plain type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6799 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Mark Lodato its...@hotmail.com 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 difficult to make a backwards-compatible wrapper around ArgumentParser. It would be much easier, and less error-prone, to leave optparse as-is and just add this module in addition. If the problem is having a third module clutter up the module list, here's a simple solution: rename the existing optparse to _optparse, rename argparse to optparse, and in (the new) optparse, from _optparse import *. Done. Now you have a backwards-compatible OptionParser (which ought to be deprecated), and the new ArgumentParser. Would this solution work? -- nosy: +marklodato ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Gregory P. Smith g...@krypto.org 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 obsolete a bunch of crappy argument parsing code that exists in some projects i work on but I haven't had time to clean them up and switch. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6800] os.exec* raises OSError: [Errno 45] Operation not supported in a multithreaded application
New submission from Reid Kleckner r...@mit.edu:
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 recent call last):
File daemon_exec.py, line 16, in module
main()
File daemon_exec.py, line 13, in main
os.execl('echo', 'hello world')
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py,
line 312, in execl
execv(file, args)
OSError: [Errno 45] Operation not supported
And on my Linux box:
hello world
Here's a similar bug that OCaml had to deal with:
http://caml.inria.fr/mantis/view.php?id=4666
I think it's reasonable for Python to declare this to be a limitation of
the OS, but considering that the other thread could be a daemon thread
that the user doesn't really care about, I think it would be reasonable
for Python to kill the other threads in the process before execing.
That's what happens on Linux, anyway.
I ran into this problem while trying to add a persistent background
compilation thread to unladen swallow, and wondered if having any other
threads would trigger the same exception.
It's tempting to just write this off, but I figured it should be
documented or left open as a low priority defect.
--
assignee: ronaldoussoren
components: Macintosh
files: daemon_exec.py
messages: 92054
nosy: rnk, ronaldoussoren
severity: normal
status: open
title: os.exec* raises OSError: [Errno 45] Operation not supported in a
multithreaded application
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14798/daemon_exec.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6800
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2204] document ConfigParser behaviour when a file has same section multiple times
trash80 tras...@trash80.org 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 the files and have the sections merged. Even merging the variables within sections would be nice. Throwing an exception, imho, is no the right direction. Even in same name sections are in the same file, the variables where introduced for a reason. Or maybe a trigger option ie action=merge or action=flag. -- nosy: +trash80 versions: +Python 3.0 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2204 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
R. David Murray rdmur...@bitdance.com 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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6800] os.exec* raises OSError: [Errno 45] Operation not supported in a multithreaded application
Ronald Oussoren ronaldousso...@mac.com 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 is unclear if that is a save thing to do (what if the system starts a number of threads in the background, killing one of them might crash your application before we get around to killing another one). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6800] os.exec* raises OSError: [Errno 45] Operation not supported in a multithreaded application
Reid Kleckner r...@mit.edu 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 bring down our background thread by another means. Unfortunately, there's no way to join pythreads, so I have to add a hack that just retries the execv call if errno == EOPNOTSUPP with an eventual timeout. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
